The RFC Archive
 The RFC Archive   RFC 109   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 109

Level III Server Protocol for the Lincoln Laboratory NIC 360/67 Host

Last modified on Friday, August 21st, 2009

Permanent link to RFC 109
Search GitHub Wiki for RFC 109
Show other RFCs mentioning RFC 109







Network Working Group                                          J. Winett
Request for Comments: 109                         MIT Lincoln Laboratory
NIC: 5805                                                  24 March 1971


          Level III Server Protocol for the Lincoln Laboratory
                              360/67 Host

Disclaimer

   This material has not been reviewed for public release and is
   intended only for use with the ARPA network.  It should not be quoted
   or cited in any publication not related to the ARPA network.

Introduction

   The Lincoln Laboratory IBM 360/67 is connected to the ARPA network
   and acts as a serving host providing access to the CP-67 virtual
   machine operating system.  Upon completion of the Login procedure,
   users have control of a 360 virtual machine through a virtual 1052
   online console.  Attached to the virtual machine is a virtual card
   reader, card punch and line printer, and a number of disk storage
   devices.  The 360 virtual machine can be either a virtual 360/67 with
   dynamic address translation hardware or a standard System/360.  Most
   users run a standard 360 with 256K bytes of virtual memory and
   operate the CMS conversational monitor system.  CMS provides
   facilities for file creation, maintenance and manipulation, program
   development, debugging and execution, and a number of other useful
   utility functions.  The section in the Network Notebook on the
   Lincoln Laboratory 360/67 more fully describes the facilities
   available.

Network Control Program

   All communication with the 360/67 through the IMP are processed by a
   Network Control Program (NCP).  The NCP operates with the Host-Host
   Protocol described in the Network Working Group Document No. 1 dated
   3 August 1970.

Initial Connection Protocol

   To create a virtual machine from the network, a pair of connections
   must be made with the LOGGER.  The sockets to be used are assigned
   following the Initial Connection Protocol (ICP).  The LOGGER is
   enabled and waiting for an RTS control command for socket X'0A 0000
   01'.  This ICP socket corresponds to home X'0A', user X'0000', and
   tag X'01' (send gender).  Requests for connection on the ICP socket
   are stacked until it becomes free.  If the LOGGER is willing to



Winett                                                       PAGE 1 top


RFC 109 Level II Server Protocol 24 March 1971 service another network user, a 32 bit socket ID of a receive socket will be sent over this initial connection and the ICP socket will then be closed. If the LOGGER is not willing to service another network user, it will not complete the initial connection for the ICP socket and will refuse the request by closing the connection without completing it. LOGGER Protocol Once a pair of user sockets have been assigned, the connection protocol should be completed on these sockets. The LOGGER then expects to receive (on the receive socket) one 8-bit byte indicating the data type which characterizes the transmission code used to communicate with the network user over this pair of sockets. A code of X'01' implies 7 bit ASCII code in 8-bit bytes with the leading bit zero. A code of X'02' implies 8-bit EBCDIC code. When the data type code is received, the LOGGER will echo back the data type code over the send socket followed by the message: LINCOLN LABORATORY CP-67 ONLINE NL in the appropriate code. (In ASCII, NL is transmitted as CR LF). The procedure continues according to the normal CP-67 login protocol with the LOGGER performing an additional function of mapping network userids and passwords into valid CP-67 userids and passwords. This mapping is specified by entries in a file (the LOGGER FILE) which the LOGGER accesses. If a network userid does not match an entry in the file or if the password given does not match the corresponding network password, the usual CP responses will be sent to the users. Thus network access to the Lincoln Laboratory system is restricted to those accounts for which an appropriate entry has been made in the LOGGER FILE. It should be noted that CP transmits a BYP code (Bypass) to suspend the printing of characters keyed while a password is being entered. After the password has been entered, CP transmits a RES code (Restore) to resume the printing when characters are keyed. When communicating in ASCII, these character codes are converted to X'FF' since no corresponding ASCII code is defined. Refer to the Network Resource Notebook for more details on CP-67 and on CMS. The NET Account Lincoln Laboratory is providing one account which can be used by network users to familiarize themselves with our time-sharing system. The userid of this account is NET and the password is ARPA. This account has 900 records of storage, which can store approximately Winett PAGE 2 top

RFC 109 Level II Server Protocol 24 March 1971 720,000 characters. NET users are free to ERASE any file on this account since many different people may use this account. The SERVER Protocol CP-67 operates on a line at a time, i.e., a group of characters are processed as a line and not as a sequence of individual characters. Also, the system does normally buffer input lines, that is, input is not normally entered until requested by a read from the system. With IBM 2741 or 1052 terminals, the keyboard is locked until a read is requested. The virtual terminals through which network users have access to the CP-67 system have been designed to support either a line oriented terminal or a character oriented terminal. When CP requests a line of input, the SERVER transmits a prompting code X'80'. This character can be used to signal a user process to change transmission modes and to transmit an input line. Characters received by the SERVER are buffered until a NL character is received. Lines received can then be used to satisfy CP requests for an input line. CP may send out lines which may or may not end with a NL character. If a line does not end with a NL character, the prompting character will naturally be sent following the output line to request input to a CP process. When a user wishes to interrupt a CP process, i.e., to change modes, an interrupt code X'80' should be sent to the SERVER. This code will result in an asynchronous interrupt being sent to the running process, stimulating the pressing of the 'attention' button on a 2741 terminal. Together with the transmission of the interrupt code, the user should cause an INS to be sent over the send link. This signal will be synchronized with the interrupt code. If the interrupt code has not yet been received and processed, all characters buffered and those received before the receipt of the interrupt code will be flushed, i.e., deleted. When the interrupt code is received, it will be paired with the previously received INS. If an INS is received after an interrupt code has been received and processed, the INS will be paired with this previously received interrupt code. If CP has a line to send to a user after it has requested an input line but before it has received any input, the SERVER will transmit an INS on the user's receive link to notify the user that previously sent prompting character should be retracted and that a line has been or will be sent to the user. This message line is called a "warning". Winett PAGE 3 top

RFC 109 Level II Server Protocol 24 March 1971 Graphic and Control Codes Figure 1 gives the 8-bit codes for the EBCDIC graphics and controls. Figure 2 gives the 7-bit codes for the ASCII graphics and controls. The controls are tabulated and compared in Figure 3. The standard interpretation of the ASCII controls are given in Figure 4. There are 4 ASCII codes which do not have a corresponding graphic or control in the EBCDIC code. The EBCDIC codes given to these codes are as follows: | Hex Code ASCII |-------+-------- Symbol | ASCII | EBCDIC -------+-------+-------- DC3 | 13 | 3A | | ` | 60 | 70 | | \ | 5C | 71 | | ^ | 5E | 72 There are 29 EBCDIC graphics codes and 19 EBCDIC control codes which do not have a corresponding graphic or control in the ASCII code. In addition, there are 84 other EBCDIC codes whose interpretation is unspecified. Four of these codes have been chosen to correspond to the ASCII control and ASCII graphics which do not have a corresponding EBCDIC code. When converting EBCDIC codes to ASCII codes, the remaining 80 codes plus the 29 EBCDIC graphics and 18 EBCDIC controls (not counting NL) are converted into the code X'FF'. The NL character is treated specially. The NL character, EBCDIC code X'15', is converted into the two character sequence CR LF, i.e., ASCII X'0D 0A'. As stated above, the code X'80' is transmitted as a prompting character whenever CP requests an input line. On converting from ASCII to EBCDIC, if any code other than the 128 ASCII codes, or the interrupt codem X'80', is received, it is converted to the code X'FF'. In addition , whenever the two ASCII characters CR LF are found sequentially in the input stream, they are converted into the single EBCDIC character NL. [In Figure 1, positions shown as "[?]" cannot be printed in ASCII.] Winett PAGE 4 top

RFC 109 Level II Server Protocol 24 March 1971 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 2 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 3 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 4567+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0000|NUL|DLE|DS | |SP | & | - | | | |[?]|[?]| | | | 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0001|SOH|DC1|SOS| | | | / | | a | j |[?]|[?]| A | J | | 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0010|STX|DC2|FS |SYN| | | | | b | k | s |[?]| B | K | S | 2 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0011|ETX|TM | | | | | | | c | l | t |[?]| C | L | T | 3 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0100|PF |RES|BYP|PN | | | | | d | m | u |[?]| D | M | U | 4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0101|HT |NL |LF |RS | | | | | e | n | v |[?]| E | N | V | 5 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0110|LC |BS |ETB|UC | | | | | f | o | w |[?]| F | O | W | 6 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0111|DEL|IL |ESC|EOT| | | | | g | p | x |[?]| G | P | X | 7 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1000| |CAN| | | | | | | h | q | y |[?]| H | Q | Y | 8 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1001| |EM | | | | | | | i | r | z |[?]| I | R | Z | 9 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1010|SMM|CC |SM | |[1]| ! | | : | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1011|VT |CU1|CU2|CU3| . | $ | , | # | { | } |[?]|[?]| | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1100|FF |IFS| |DC4| < | * | % | @ |[?]|[?]|[?]|[?]| | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1101|CR |IGS|ENQ|NAK| ( | ) | _ | ' |[?]|[?]| [ | ] | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1110|SO |IRS|ACK| | + | ; | > | = |[?]|[?]|[?]|[?]| | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1111|SI |IUS|BEL|SUB| | |[2]| ? | " |[?]|[?]|[?]|[?]| | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +---+---+---+---+---+---+---+---+ Code Structure Figure 1. Extended Binary-Coded Decimal Interchange Code (EBCDIC) Winett PAGE 5 top

RFC 109 Level II Server Protocol 24 March 1971 8 0 0 0 0 0 0 0 0 7 0 0 0 0 1 1 1 1 6 0 0 1 1 0 0 1 1 5 0 1 0 1 0 1 0 1 4321+---+---+---+---+---+---+---+---+ 0000|NUL|DLE|SP | 0 | @ | P | ` | p | +---+---+---+---+---+---+---+---+ 0001|SOH|DC1| ! | 1 | A | Q | a | q | +---+---+---+---+---+---+---+---+ 0010|STX|DC2| " | 2 | B | R | b | r | +---+---+---+---+---+---+---+---+ 0011|ETX|DC3| # | 3 | C | S | c | s | +---+---+---+---+---+---+---+---+ 0100|EOT|DC4| $ | 4 | D | T | d | t | +---+---+---+---+---+---+---+---+ 0101|ENQ|NAK| % | 5 | E | U | e | u | +---+---+---+---+---+---+---+---+ 0110|ACK|SYN| & | 6 | F | V | f | v | +---+---+---+---+---+---+---+---+ 0111|BEL|ETB| ' | 7 | G | W | g | w | +---+---+---+---+---+---+---+---+ 1000|BS |CAN| ( | 8 | H | X | h | x | +---+---+---+---+---+---+---+---+ 1001|HT |EM | ) | 9 | I | Y | i | y | +---+---+---+---+---+---+---+---+ 1010|LF |SUB| * | : | J | Z | j | z | +---+---+---+---+---+---+---+---+ 1011|VT |ESC| + | ; | K | [ | k | { | +---+---+---+---+---+---+---+---+ 1100|FF |FS | , | < | L | \ | l | | | +---+---+---+---+---+---+---+---+ 1101|CR |GS | - | = | M | ] | m | } | +---+---+---+---+---+---+---+---+ 1110|SO |RS | . | > | N | ^ | n | ~ | +---+---+---+---+---+---+---+---+ 1111|SI |SU | / | ? | O | _ | o |DEL| +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+ | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | +---+---+---+---+---+---+---+---+ Code Structure Figure 2. USA Standard Code for Information Interchange (USASCII) Winett PAGE 6 top

RFC 109 Level II Server Protocol 24 March 1971 CAT EBCDIC ASCII TTY PTTC FUNCTION NUL NUL NULL Null CC SOH SOH SOM Start of Heading CC STX STX EOA EOA (D) Start of Text CC ETX ETX EOM End of Text DC PF PF Punch Off FE HT HT H.TAB TAB Horizontal Tab GR LC LC Lower Case DEL DEL RUBOUT DEL Delete SMM Start of Manual Message FE VT VT V.TAB Vertical Tab FE FF FF FORM Form Feed FE CR CR RETURN Carriage Return GR SO SO SO Shift Out GR SI SI SI Shift In CC DLE DLE DC0 Data Link Escape DC DC1 DC1 X-ON Device Control 1 DC DC2 DC2 TAPE ON Device Control 2 TM Tape Mark DC RES RES Restore FE NL NL New Line FE BS BS BS Backspace IL IL Idle CAN CAN FE0 CAN Cancel EM EM S1 End of Medium CC Cursor Control CU CU1 Customer Use 1 IS IFS FS S4 Info. Field Separator IS IGS GS S5 Info. Group Separator IS IRS RS S6 Info. Record Separator IS IUS US S7 Info Unit Separator ED DS Digit Select ED SOS Start of Significance ED FS Field Separator DC BYP BYP Bypass FE LF LF LF LF Line Feed CC ETB ETB LEM EOB (B) End of Text Block ESC ESC S3 PRE Escape SM Set Mode CU CU2 Customer Use 2 CC ENQ ENQ WRU Enquiry CC ACK ACK RU (Y) Acknowledge BEL BEL BELL Bell CC SYN SYN SYNC Synchronous Idle DC PN PN Punch On DC RS RS Reader Stop GR UC UC Upper Case Winett PAGE 7 top

RFC 109 Level II Server Protocol 24 March 1971 CC EOT EOT EOT EOT (C) End of Transmission CU CU3 Customer Use 3 DC DC4 DC4 TAPE OFF Device Control 4 CC NAK NAK ERROR (N) Negative Acknowledge SUB SUB S2 Substitute DC DC3 X-OFF Device Control 3 Figure 3 Control Functions Compared CC (Communication Control). A functional character intended to control or facilitate transmission of information over communication networks. FE (Format Effector). A functional character which controls the layout or positioning of information in printing or display devices. IS (Information Separator). A character which is used to separate and qualify information in a logical sense. There is a group of four such characters, which are to be used in a hierarchical order. DC (Device Control). A functional character used for the control of ancillary devices associated with data processing of telecommunication systems, more especially switching devices "on" and "off". ED (Edit and Mark). A control character used by the System/360 Edit and Mark (EDMK) instruction for the formatting of alphanumeric fields. GB (Graphic Control). A control character indicating that the code combinations which follow are to be interpreted in a particular code table, depending upon the particular control character. CU (Customer Use). A character excluded from future assignment by IBM. These "protected" codes are intended for use by customer systems so that their use will not conflict with a possible future IBM use. Figure 3 (Continued) Categories of Control Functions Winett PAGE 8 top

RFC 109 Level II Server Protocol 24 March 1971 NUL (Null). The all-zeros character which may serve to accomplish time fill and media fill. SOH (Start of Heading). A communication control character used at the beginning of a sequence of characters which constitute a machine-sensible address or routing information. Such a sequence is referred to as the _heading_. An STX character has the effect of terminating a heading. STX (Start of Text). A communication control character which precedes a sequence of characters that is to be treated as an entity and transmitted through to the ultimate destination. Such a sequence is referred to as _text_. SIX may be used to terminate a sequence of characters started by SOH. ETX (End of Text). A communication control character used to terminate a sequence of characters started with STX and transmitted as an entity. EOT (End of Transmission). A communication control character used to indicate the conclusion of a transmission, which may have contained one or more texts and any associated headings. ENQ (Enquiry). A communication control character used in data communication systems as a request for a response from a remote station. It may be used as a "Who Are You" (WRU) to obtain identification, or may be used to obtain station status, or both. ACK (Acknowledge). A communication control character transmitted by a receiver as an affirmative response to a sender. BEL (Bell). A character for use when these is a need to call for human attention. It may control alarm or attention devices. BS (Backspace). A format effector which controls the movement of the printing position one printing space backward on the same printing line (applicable also to display devices). HT (Horizontal Tabulation). A format effector which controls the movement of the printing position to the next in a series of predetermined positions along the printing line (applicable also to display devices and the skip function on punched cards.) LF (Line Feed). A format effector which controls the movement of the printing position to the next printing line (also applicable to display devices). Winett PAGE 9 top

RFC 109 Level II Server Protocol 24 March 1971 VT (Vertical Tabulation). A format effector which controls the movement of the printing position to the next in a series of predetermined printing lines (also applicable to display devices). FF (Form Feed). A format effector which controls the movement of the printing position to the first predetermined printing line on the next form or page (also applicable to display devices). CR (Carriage Return). A format effector which controls the movement of the printing position to the first printing position on the same printing line (also applicable to display devices). SO (Shift Out). A control character indicating that the code combinations which follow shall be interpreted as outside of the character set of the standard code table until a Shift In Character is reached. SI (Shift In). A control character indicating that the code combinations which follow shall be interpreted according to the standard code table. DLE (Data Link Escape). A communication control character which will change the meaning of a limited number of contiguously following characters. It is used exclusively to provide supplementary controls in data communication networks. DC1, DC2, DC3, DC4 (Device Controls). Characters for the control of ancillary devices associated with data processing or telecommunication systems, more especially switching devices "on" and "off". (If a single "stop" control is required to interrupt of turn off ancillary devices, DC4 is the preferred assignment.) NAK (Negative Acknowledge). A communication control character transmitted by a receiver as a negative response to a sender. SYN (Synchronous Idle). A communication control character used by a synchronous transmission system in the absence of any other character to provide a signal from which synchronism may be achieved or retained. Winett PAGE 10 top

RFC 109 Level II Server Protocol 24 March 1971 ETB (End of Transmission Block). A communication control character used to indicate the end of a block of data for communication purposes. ETB is used for blocking data where the block structure is not necessarily related to the processing format. CAN (Cancel). A control character used to indicate that the data with which it is sent is in error or is to be disregarded. EM (End of Medium). A control character associated with the sent data which may be used to identify the physical end of the medium, or the end of the used, or wanted, portion of information recorded on a medium. (The position of this character does not necessarily correspond to the physical end of the medium. SS (Start of Special Sequence). A control character used to indicate the start of a variable length sequence of characters which have special significance or which are to have special handling. ESC (Escape). A control character intended to provide code extension (supplementary characters) in general information interchange. The Escape character itself is a prefix affecting the interpretation of a limited number of contiguously following characters. FS (File Separator), GS (Group Separator), RS (Record Separator) and US (Unit Separator). These information separators may be used within data in optional fashion, except that the hierarchical relationship shall be : FS is the must inclusive, then GS, then RS, and US is least inclusive. (The content and length of a File, Group, Record, or Unit are not specified.) DEL (Delete). This character is used primarily to "erase" or "obliterate" erroneous or unwanted characters in perforated tape. (In the strict sense, DEL is not a control character.) Figure 4 ASCII Control Functions Winett PAGE 11 top

RFC 109 Level II Server Protocol 24 March 1971 Endnotes [1] - Cent sign [2] - Logical not ("bent bar") [?] - Graphics not in ASCII. See Postscript or PDF version of this document. [This RFC was put into machine readable form for entry] [into the online RFC archives by Lorrie Shiota, 10/02] Winett PAGE 12 top

Level III Server Protocol for the Lincoln Laboratory NIC 360/67 Host RFC TOTAL SIZE: 27716 bytes PUBLICATION DATE: Friday, August 21st, 2009 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 109: The IETF Trust, Friday, August 21st, 2009
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement