rfc138.txt

RFC 的详细文档！

   To insert a field, separate the input into the two terms to allow the
   inserted field between them.  For example, to do line numbering for a
   121 character/line printer with a leading carriage control character,
   use the following form.

   (NUMB.<=>.1);       /*initialize line number counter to one*/
   1 CC(,E,,1:F(R(99))),  /*pick up control character and save
                            as CC*/
                          /*return a code of 99 upon exhaustion*/
   LINE(,E,,121 : F(R(98)))    /*save text as LINE*/
   :CC,               /*emit control character*/
   (,E,NUMB,2),       /*emit counter in first two columns*/
   (,E,E".",1),       /*emit period after line number*/
   (,E,LINE,117),     /*emit text, truncated in 117 byte field*/
   (NUMB.<=.NUMB+1:U(1));    /*increment line counter and go to
                               rule one*/;;

DELETION

   Data to be deleted should be isolated as separate terms on the left,
   so they may be omitted (by not emitting them) on the right.

   (,B,,8),           /*isolate 8 bits to ignore*/
   SAVE(,A,,10)       /*extract 10 ASCII characters from
                        input stream*/
   :(,E,SAVE,);      /*emit the characters in SAVE as EBCDIC
                       characters whose length defaults to the
                       length of SAVE, i.e., 10, and advance to
                       the next rule*/

   In the above example, if either input stream term fails,
   the next sequential rule is applied.

VARIABLE LENGTH RECORDS

   Some devices, terminals and programs generate variable length
   records.  To following rule picks up variable length EBCDIC records



Anderson, et al.                                               [Page 18]

RFC 138               Data Reconfiguration Service          April 1971


   and translates them to ASCII.

   CHAR(,E,,#),       /*pick up all (an arbitrary number of)
                        EBCDIC characters in the input stream*/
   (,X,X"FF",2)       /*followed by a hexadecimal literal,
                        FF (terminal signal)*/
   :(,A,CHAR,),       /*emit them as ASCII*/
   (,X,X"25",2);      /*emit an ASCII carriage return*/

STRING LENGTH COMPUTATION

   It is often necessary to prefix a length field to an arbitrarily long
   character string.  The following rule prefixes an EBCDIC string with
   a one-byte length field.

   Q(,E,,#),          /*pick up all EBCDIC characters*/
   TS(,X,X"FF",2)     /*followed by a hexadecimal literal, FF*/
   :(,B,L(Q)+2,8),    /*emit the length of the characters
                        plus the length of the literal plus
                        the length of the count field itself,
                        in an 8-bit field*/
   Q,                 */emit the characters*/
   TS;                */emit the terminal*/

TRANSPOSITION

   It is often desirable to reorder fields, such as the following
   example.

   Q(,E,,20), R(,E,,10) , S(,E,,15), T(,E,,5) : R, T, S, Q ;

   The terms are emitted in a different order.

CHARACTER PACKING AND UNPACKING

   In systems such as HASP, repeated sequences of characters are packed
   into a count followed by the character, for more efficient storage
   and transmission.  The first form packs multiple characters and the













Anderson, et al.                                               [Page 19]

RFC 138               Data Reconfiguration Service          April 1971


   second unpacks them.
   /*form to pack EBCDIC streams*/
   /*returns 99 if OK, input exhausted*/
   /*returns 98 if illegal EBCDIC*/
   /*look for terminal signal FF which is not a legal EBCDIC*/
   /*duplication count must be 0-254*/
   1 (,X,X"FF",2 : S(R(99))) ;
   /*pick up the EBCDIC and initialize count/*
     CHAR(,E,,1 : F(R(98))) , (CNT .<=. 1) ;
   /*count consecutive EBCDICs like CHAR*/
   2 (,E,CHAR,1 : F(3)) , (CNT .<=. CNT+1 : U(2)) ;
   /*emit count and current character*/
   3 : (,B,CNT,8), CHAR, (:U(1));
   /*end of form*/;;

   /*form to unpack EBCDIC streams*/
   /*look for terminal*/
   1 (,X,X"FF",2 : S(R(99))) ;
   /*emit character the number of times indicated*/
   /*by the counter contents*/
   CNT(,B,,8), CHAR(,E,,1) : (CNT,E,CHAR,CNT:U(1));
   /*failure of form*/
   (:U(R(98))) ;;


V.  PROPOSED USES OF DATA RECONFIGURATION SERVICE

   The following are some proposed uses of the DRS that were submitted
   by the sites indicated.

   UCLA
   1.  Pack/unpack text files.
   2.  Preprocessor to scan META compiler input.
   3.  Perhaps graphics.

   MIT
   1.  Reformatting within file transfer service.
   2.  Character conversions.
   3.  Possible graphics service (Evans and Sutherland output
       format).
   4.  Reformat arguments of subroutines remote to each other.

   U. OF ILLINOIS
   1.  Dependent upon remote use of DRS for many remote
       services.

   SDC
   1.  Would be essential to data transfer in general.



Anderson, et al.                                               [Page 20]

RFC 138               Data Reconfiguration Service          April 1971


   2.  Could be used in relation to data management language.

   UCSB
   1.  Checkout of I/O formats of file system.
   2.  Debugging Network services in general.
   3.  Mapping their services into future standards.

   RAND
   1.  To describe RJO/RJE message formats at UCSB.
   2.  To describe RJS message formats at UCLA.
   3.  To adapt Network to existing services, in general.

   MITRE
   1.  Character conversions.
   2.  Testing data formats going into data bases for correct
       field formatting.

   VI.  IMPLEMENTATION PLANS

   Four sites currently plan to implement and offer the service on an
   experimental basis.

   1.  MIT    Implementation of forms interpreter in MIDAS
              (assembly).  Perhaps Tree Meta compiler of
              forms.  Implementation on PDP-10.

   2.  UCLA   Implementation on SIGMA-7 employing META-7
              to compile forms.

   3.  UCSB   Implementation on 360/75.

   4.  RAND   Initial implementation on 360/65; compiler to be written
               in graphics CPS; compiled intermediate forms to be
               interpreted by assembler language subroutine.  Later
               implemented on PDP-10.

   In addition to the above sites, the University of Illinois and Mitre
   plan to experiment with the service.













Anderson, et al.                                               [Page 21]

RFC 138               Data Reconfiguration Service          April 1971


                                APPENDIX A

Note 1 to the DRS Working Group

   As you recall, we spent considerable time in discussing the use and
   meaning of the arbitrary symbol, #.  To summarize, it was clear that
   inclusion of the # in both replication and length expressions led to
   ambiguities.  We settled on its restricted use in the length
   expression of an input term, although no one was entirely satisfied
   with this definition.

   Recently, Jim White has again commented on the #.  Jim feels that it
   is curious that one can pick up an arbitrary number of EBCDIC
   characters, for example, but can't pick up an arbitrary number of
   specific EBCDIC characters such as EBCDIC A's.  Jim feels that a more
   natural way to interpret the length, value, and replication
   expressions would be as the IBM OS assembler interprets the
   attributes of the pseudo instruction, define constant (CD).

   The IBM OS assembler uses the following format.

        1             2              3           4
   duplication       type        modifiers   nominal value
     factor

   The duplication factor, if specified, causes the constant to be
   generated the number of times indicated by the factor.  The type
   defines the type of constant being specified.  Modifiers describe the
   length, scaling, and exponent of the constant.  Nominal value
   supplies the constant described by the subfields that precede it.

   Assume that we use the # only as a duplication factor (replication
   expression).  Hence, in the example of the form to pack EBCDIC
   characters, the counter and looping can be eliminated.

   CHAR(,E,,1) ;
   LEN(#,#,CHAR,1) : (,B,L(LEN)+1,*) , CHAR ;

   The interpretation is that the data type, length expression, and
   value expression make up the unit value.  This quantity can then be
   replicated.  As our document now stands, only the data type and value
   expression make up the unit value.

   The application of a term according to Jim's suggestion is as
   follows.
   1.  The data type, value expression, and length expression together
       specify a unit value, call it x.




Anderson, et al.                                               [Page 22]

RFC 138               Data Reconfiguration Service          April 1971


   2.  The replication expression specifies the number of times x is to
       be repeated.  The value of the concatenated xs becomes y of
       length L.
   3.  If the term is an input stream term then the value beginning at
       the current input pointer position.
   4.  If the input value satisfies the constraints of y over length L
       then the input value of length L becomes the value of the term.

Note 2 to the DRS Working Group

   There has been recent debate of whether the input pointer should be
   advanced upon successful completion of a rule (as it now is defined)
   or upon successful completion of each term.  See the example on page
   22.  If the input pointer is advanced upon successful completion of a
   term, then rules become equivalent to terms.

   I would like to for us to discuss at the SJCC both the term
   attributes and the input pointer advance issues.

                                                John


       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Katsunori Tanaka 4/99 ]



























Anderson, et al.                                               [Page 23]