Received at NIC 14-DEC-73
RFC589
NIC #20268
Robert T. Braden
UCLA/CCN
November 26, 1973
CCN NETRJS SERVER
MESSAGES TO REMOTE USER

A. _I_N_I_T_I_A_L _C_O_N_N_E_C_T_I_O_N, _S_I_G_N_O_N, _A_N_D _S_I_G_N_O_F_F

     1.   If CCN refuses an ICP to a NETRJS socket, it means either that
     
          there is no free core within the NCP region, or that CCN's
          software is crashing.
     
     2.   Once ICP is completed, CCN might send the user one of the fol-
          lowing messages and close the Telnet connections:

NRJ110I NETRJS PORTS BUSY. TRY LATER

This may be expected occasionally; frequent occurrance
should be reported to CCN User Relations (825-7548), or
to BELL@CCN.

NRJ111I RJS NOT UP, TRY LATER

     3.   Normally, however, the user will receive a READY message:

NRJ876R CCN NETRJS READY. ENTER SIGNON

If the user sends no operator input for 3 minutes, CCN will
send:

NRJ308R SIGNON TIMEOUT EXCEEDED

NRJ205R NETRJS SESSION TERMINATED

and close the Telnet connection. If he sends an invalid SIG-
NON command, he will receive the message:

NRJ307R INVALID SIGNON, RE-ENTER

7 Finally, a valid signon will be acknowledged by RJS with the

message:

RJS750I TERMINAL -termid- HAS SIGNED ONTO RJS

     4.   If the user terminates the session by entering a SIGNOFF com-
          mand, NETRJS will wait until all data transfer has completed
          before sending the message:

NRJ205R NETRJS SESSION TERMINATED

and closing the Telnet connection.

B. _R_E_M_O_T_E _S_I_T_E _O_R _N_E_T_W_O_R_K _F_A_I_L_U_R_E_S

     1.   During data transfer, the user must be reasonably responsive.
          If not, CCN will close the data transfer connection and send
          the remote operator message:
     
               NRJ504I DATA TRANSFER TIMEOUT FOR THE -device-, -termid-
     
                    a)   if -device- is PRINTER or PUNCH, user site
                         stopped accepting bits (sending "allocates")
                         for over 5 minutes.
     
                    b)   if -device- is READER, user site left reader
                         connection open without sending any bits for 5
                         minutes.
     
     2.   During data transfer on the CR connection, CCN may detect an
          incorrect header or record, presumably due to user site
          software or Network transmission error.  The following mes-
          sages beginning with the word "BAD" will follow an NRJ512I
          message containing the faulty header in hex:

NRJ505I BAD HEADER SEQUENCE FOR NETRJS READER

Sequence number in transaction header does not match
internal counter of records passed.

NRJ506I BAD HEADER LENGTH FOR NETRJS READER

Length given in header exceeds 880 bytes.

7 NRJ507I BAD HEADER TYPE FOR NETRJS READER

Type code in header is not X'FF' (data) or X'FE'
(end-of-data)

NRJ511I BAD FILL BIT COUNT FOR NETRJS READER

The filler bit count in header is not a multiple of
8.

     3.   If the header is correct but a data record is faulty, the fol-
          lowing message will be sent to a remote user:
     
               NRJ602I line STREAM ERROR - READER, -code-

A protocol error was detected in the READER stream.
CCN will close the stream and ready it to be reo-
pened so the remote user may retry the data transfer
operation. The valid -code- values are:

     _C_O_D_E            _E_R_R_O_R
     
       1             Device id byte has high bit off.
     
       2             End of transaction in the middle of a data line.
     
       3             Truncated input line longer than 255 bytes.
     
       4             In compressed text, string control byte has high
                     bit off.
     
       5             In compressed text, duplicate blank string extends
                     line longer than 255 bytes.
     
       6             In compressed text, duplicate character string
                     extends line longer than 255 bytes.
     
       7             In compressed text, character string extends line
                     longer than 255 bytes.
     
     4.   Finally, if the user aborts his data transfer, he receives the
          message:

NRJ502I NETRJS -device- DATA TRANSFER ABORTED BY USER
-termid-.

7C. _C_C_N _F_A_I_L_U_R_E_S

     1.   The CCN operator can cancel a NETRJS session, aborting any
          open data transfer streams and sending the message:

NRJ204I NETRJS SESSION ABORTED BY CENTRAL OPERATOR, TERM=
-termid-

     2.   Any of the following messages indicate a serious CCN Network
          software problem, and will cause the session to be aborted:

NRJ106A NETRJS DEAD - EXCHANGE INOPERATIVE

NRJ201A NETRJS DT SOCKET ERROR - BAD LISTEN

               NRJ208A NETRJS PROGRAM CHECK IN -device-, code=ccc
               
               NRJ209A NETRJS LOAD FAILED FOR -device-, code=xx

NRJ304I RJS LINE HANDLER DEAD

NRJ401I RJS LINE HANDLER DEAD

NRJ402I RJS LINE HANDLER DEAD

Any of these should be reported to CCN.

     3.   Besides global catastrophes like these above, the user might
     
          encounter a failure of a particular data transfer process.
          These do not terminate the session, only cause the data con-
          nection to be refused or terminated; the user can try again to
          open the data connection.  Repeated failure should be reported
          to CCN.

NRJ501I NO CORE FOR DATA TRANSFER BUFFER -device-

NRJ503I NO CORE FOR DATA TRANSFER WORKAREA -device-

NRJ207I NO CORE FOR-device-DATA TRANSFER MODULE

Due to core memory limitations in CCN's NCP,
-device- cannot be started now. The data transfer
connection indicated by -device- will be refused.
This may happen occasionally during active periods,
but repeated occurrences should be reported to CCN.

7 NRJ509I -device- DATA TRANSFER DEAD

               NRJ510I -device- DATA TRANSFER DEAD
               
               NRJ602I line STREAM ERROR - PRINTER, -code-
               
               NRJ602I line STREAM ERROR - PUNCH, -code-

CCN data transfer failed, but recovery may be possi-
ble. User may try again.

            [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Tony Hansen 10/98     ]