Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
Updated by:217Network Working Group James E. WhiteRequest for Comments: 105 Computer Research Lab.Category: Informational University of California Santa Barbara, California March 1971Network Specifications forRemote Job Entryand Remote Job Output Retrieval at UCSB In the discussions that follow, 'byte' means 8 bits, with thoseeight bits numbered 0-7 from left to right.I - Remote Job Entry (RJE) UCSB will accept input of pseudo card files for batch processingat socket number x'200', site 3. Network users should obtain anaccount number from the UCSB Computer Center; account #1025,programmer names 'UCLA', 'SRI', 'UTAH', etc. may be used duringcheckout. The 360/75 runs under OS MVT and HASP. Users submit jobsto HASP for scheduling and subsequent execution by OS through anintermediary process hereafter called RJE which is addressed as socketnumber x'200' and can be invoked through the Logger. This section isintended to provide programmers with the information necessary tocommunicate with RJE; the is assumed familiar with the batch servicesoffered by the Computer Center, and with its job control language(JCL) requirements. RJE conducts all Network transactions through the NCP, whichoperates under the Host-Host protocol of 3 August 1970. It expectsthe first message it receives to be Type 0, discards the first eightbits (the message type) assuming them to be zeros, and thereafter forthe life of the connection takes no notice of IMP-message boundaries.I.A - Logging into RJE To submit one or more jobs for batch processing, the Network usermust establish a simplex connection with RJE. RJE is core residentonly while such a simplex connection is established (i.e., while auser is transmitting a file). At all other times, it resides ondirect-access storage and must be invoked through the Logger. A loginsequence can always be initiated by requesting connection to socketx'200'. RJE does not serve multiple users simultaneously. This if aconnection request is made to that socket while RJE is in use, the NCPwill queue the request. When the current file transmission isWhite [Page 1]
RFC 105 RJE at UCSB March 1971complete, RJE will listen for and accept the next request (if any) inits queue; if no requests are queued for it, it will terminateexecution, releasing the main storage it occupied. At times when RJEis not in core, the Logger listens on socket x'200', and will rejectthe first call it receives, read RJE into core, and dispatch it. RJEwill then list on that socket. Thus to initiate a login sequence, theuser requests connection to socket x'200'. If accepted, he is incontact with RJE. If rejected, he should reissue the connectionrequest; when accepted, he will be connected to RJE. A secondrejection would indicate that the NCP's resources were exhausted.Once the connection has been established, RJE will consider the userlogged in. To prevent RJE from being monopolized by a single user, provisionis made within the software for terminating a connection if RJE isever required to wait more than a certain amount of time for atransmission from the connected user. For now, this time limit hasbeen set at one minute per record, but it may be shortened orlengthened as required in the future. Barring such termination, RJEwill maintain its connection to the user indefinitely. Card imageswill be accepted over the connection, and each one will be passed toHASP as it is received. The user is expected to close the connectiononce his file has been transmitted. RJE will interpret that action asan end-of-file indication, and the user will be considered logged off.I.B - The RJE Connection RJE expects the first byte of data it receives over theconnection established with it to be zeros, indicating message Type 0;it discards this byte unexamined, and thereafter, attaches nosignificance to IMP-message boundaries. The second byte of datareceived is interpreted as flags specifying the format of the data(file) to follow. The byte is interpreted as follows: Bits 0-1 = 00: file follows as Class A (stream-oriented) input. = 01: not defined, should not occur. = 10: file follows as Class B (variable-length record) input. = 11: file follows as Class C (fixed-length record) input. Bits 2-7 : not examined, should be zeros.Once made, this declaration prevails for the life of the connection. Regardless of the input class specified, the user transmits hisfile as card images, each of which will be padded on the right withblanks or truncated on the right to 80 bytes if necessary. The fileWhite [Page 2]
RFC 105 RJE at UCSB March 1971transmitted must be structured exactly as if it were being placed onthe card reader at the Computer Center. A job card and all the other,usual JCL must be present for each job in the file (batching of jobsis permissible and is transparent to RJE). For any job which requiresthat special (non-resident) disk(s) and/or tape(s) to be mounted, aspecial JCL card must be inserted immediately after the job card forthat job, and it must have the format: /*SETUP vol-ser , vol-ser ,... 1 2where 'vol-ser ' is the volume serial number of a volume requiring imounting. '/*SETUP' begins in column 1; 'vol-ser ' must begin in 1column 16. The job will then enter the System in a HASP hold statusuntil the required volume(s) can be mounted by the operator. If theuser neglects to declare all such required volumes, his job is subjectto immediate cancellation. All cards of the file which are notcontained in a SYSIN data set must consist of valid, EBCDICcharacters.I.B.1 - Class A (Stream-Oriented) Input If input to RJE has been declared as Class A, the third byte of datareceived over the connection by RJE is interpreted as a break characterdeclaration. Each byte received thereafter is compared to thatcharacter. Any other character is taken to be the next byte of thecurrent card image. Whenever the break character is encountered, theprevious byte is taken to be the last byte of the current card image,which is then padded or truncated as required and passed to HASP. Zeroor more non-break characters may occur between occurrences of the breakcharacter. Thus when Class A input is specified, data transmitted toRJE shall have the following form: 1 1 1 variable 1+-------+-------+-------+ / +------//--------+-------+ \| | | BREAK | / | | BREAK | \| x'00' | x'00' | CHAR. | \ | CARD IMAGE | CHAR. | / ...+-------+-------+-------+ \ +------//--------+-------+ /where the length of each field has been specified in bytes. Zero ormore occurrences of the quantity in parentheses [angle brackets] may betransmitted before the connection is closed by the user.I.B.2 - Class B (Variable-Length Record) Input If input to RJE has been declared as Class B, then all input afterWhite [Page 3]
RFC 105 RJE at UCSB March 1971the initial two bytes is expected to consist of a contiguous string ofvariable length records, each consisting of a one-byte op code (the opcode should be x'01'), a two-byte length field which specifies theunsigned length in bits of the variable-length text field which follows.The text field may be zero or more bytes in length; the length fieldmust contain an integer which is a multiple of 8. The text fieldrepresents one card image, which is padded or truncated by RJE asrequired and passed to HASP. Thus when Class B input is specified, datatransmitted to RJE shall have the form: 1 1 1 2 L bits+-------+-------+ / +-------+-------+-----//-----+ \| | | / | | | TEXT | \| x'00' | x'80' | \ | x'01' | L | card image | / ...+-------+-------+ \ +-------+-------+-----//-----+ /where the length of each field has been specified in bytes, except wherestated to the contrary. Zero or more occurrences of the quantity inparentheses [angle brackets] may be transmitted before the connection isclosed.I.B.3 - Class C (Fixed-Length Record) Input If input to RJE has been declared as Class C, then all input afterthe initial two bytes is expected to consist of a contiguous string offixed-length, 80-byte card images. Thus, when Class C input isspecified, data transmitted to RJE shall have the form: 1 1 80+-------+-------+ / +--------------------+ \| | | / | | \| x'00' | x'C0' | \ | card image | / ...+-------+-------+ \ +--------------------+ /where the length of each field has been specified in bytes. Zero ormore occurrences of the quantity in parentheses [angle brackets] may betransmitted before the connection is closed.II - Remote Job Output Retrieval (RJOR) Class A SYSOUT output from jobs submitted through RJE for batchprocessing at UCSB may be obtained by contacting socket x'300', site 3,provided that when the job was submitted, the character 'T' appeared asthe eighth positional accounting parameter on the job card. Output isretrieved upon request and relayed to the Network user by a processhereafter called RJOR which is addressed as socket x'300'. RJOR can beinvoked through the Logger. This section is intended to provideprogrammers with the information necessary to communicate with RJOR.White [Page 4]
RFC 105 RJE at UCSB March 1971 RJOR conducts all Network transactions through the NCP, whichoperates under the Host-Host protocol of 3 August 1970. RJOR expectsthe first message it receives to be Type 0, discards the first byte,assuming it to be zeros, and thereafter for the life of the connectiontakes no notice of IMP-message boundaries. Similarly, the first messagesent by RJOR is of Type 0: the first byte consists of zeros, andthereafter for the life of the connection, IMP-message boundaries arenot significant.II.A - Logging into RJOR To obtain output from a batch-mode job, the Network user mustestablish a full duplex connection with RJOR. RJOR is core residentonly while in use (i.e., while control information or a file is beingtransmitted to or from a user, or while RJOR is waiting for a previouslyrequested output file (or files)). At all other times, it resides ondirect-access storage and must be invoked through the Logger. A loginsequence can always be initiated by requesting connection to socketx'300'. If a connection request is made to that socket while anotheruser is being logged in, the NCP will queue the request. After thecurrent connection is terminated, RJOR will listen for and accept thenext request (in any) in its queue; if no requests are queued for it andif it has fulfilled all of its output file requests, it will terminateexecution, releasing the main storage it occupied. At times when RJORis not in core, the Logger listens on socket x'300', and will reject thefirst call it receives, read RJOR into core, and dispatch it. RJOR willthen listen on that socket. Thus to initiate a login sequence, the userrequests connection to socket x'300'. If accepted, he is in contactwith RJOR. If rejected, he should reissue the connection request; whenaccepted, he will be connected to RJOR. A second rejection wouldindicate that the NCP's resources were exhausted. Once this first halfof the required duplex connection has been established, RJOR willconsider the user logged in. Over this first connection (hereafter called the Input Connection),the user transmits flags designating the function(s) to be performed byRJOR, and the name of the job to which the function(s) is(are) to beapplied. RJOR then closes this connection. RJOR transmits controlinformation specifying the disposition of the user's request and theoutput file (if requested) over a secondary connection involving RJOR'ssocket number x'301', site 3, and the socket at the user's site whosesocket number is one less than that on which RJOR was contacted by theuser. The user's request may or may not be immediately executable. Ifthe former is the case, RJOR issues a connection request to thedesignated user receive socket, and when the connection is establishedtransmits whatever control information is appropriate along with theuser's output (if required); RJOR then closes the connection and theuser is considered logged out. If the user's request cannot beWhite [Page 5]
RFC 105 RJE at UCSB March 1971immediately satisfied (e.g., the job whose output is sought hasn't beensubmitted yet or hasn't finished execution), the second connection isopened by RJOR just long enough to inform the user of the delay, andthen closed. Then when the request can be serviced, the connection isreopened, the required data transmitted, and the connection closed; theuser is then considered logged out. To prevent RJOR from being monopolized by a single user, provisionis made within the software for terminating a connection if RJOR is everrequired to wait more than a certain amount of time for completion of atransmission to or from the connected user. For now, this time limithas been set at one minute per record, but it may be shortened orlengthened as required in the future.II.B - The Input Connection RJOR expects the first byte of data it receives over the InputConnection to be zeros, indicating message Type 0; it discards this byteunexamined, and thereafter, attaches no significance to IMP-messageboundaries. The second byte of data received is interpreted as flagsspecifying the function(s) to be performed. Following the flag byte,RJOR expects an eight-byte, EBCDIC job name, padded on the right withblanks if necessary. The flag byte is interpreted as follows: Bit 0 = 1: transmit the output generated by the specified job. Bit 1 = 1: purge the output file created by the specified job. Bit 2 = 1: wait as long as is required to execute the function(s) specified by Bits 0-1. = 0: if the function(s) specified by Bits 0-1 cannot be executed immediately, simply return an indication of that fact. Bit 3 = 1: an earlier request pertaining to the specified job which exercised the wait-for-output (Bit 2) option is to be canceled. Bits 4-7: not examined, should be zeros.Any combination of Bits 0-2 is permissible. If Bit 3 = 1, no other bitsare examined. If Bit 0 = 1 and Bit 1 = 1, the output file istransmitted before it is purged. If two jobs with the same name areexecuted in succession, output from the second job will overlay thatproduced by the first. In such cases, the user should purge the outputfrom the first job after it has been transmitted to him so that arequest for output from the second job will not simply return a secondcopy of the first job's output.II.C - The Output Connection RJOR may open the output connection either one or two times as theWhite [Page 6]
RFC 105 RJE at UCSB March 1971result of a single transmission on the Input Connection. In each case,the first byte transmitted will consist of zeros indicating message Type0, and thereafter for the life of the connection, IMP-message boundariesare not significant. Following the first byte, RJOR will transmit thename of the job to which the response applies. The job name will becontained in an 8-byte field identical to that supplied by the user overthe Input Connection. Following the job name, RJOR will transmit zeroor more variable length logical records. Each will consist of a one-byte op code, a two-byte length field which specifies the unsignedlength in bits of the variable length text field which follows. Thetext field may be zero or more bytes in length; the length field willcontain an integer which is a multiple of eight. The op codes presently defined are listed in Figure 1. An op codeof x'01' indicates that the text field contains one record of one of theSYSOUT data sets created by the job whose output was requested. Thelength fields of all logical records with an op code of x'01' will beidentical. For data sets with record lengths other than this value,records are padded on the right side with blanks or truncated on theright to this standard record length. Carriage control characters whichwould ordinarily appear in column 1 for printer-destined output havebeen discarded and do not appear.* The records are transmitted to theuser in the same sequence as they would be printed on the printer, andcollectively include everything that would appear in printed output withthe exception of HASP separator sheets. In all logical records but those with an op code of x'01', thelength field contains the value zero, and the op code conveys the entiremeaning of the logical record.________________________________________________________________________*This restriction is temporary; a fix is in the works and will beannounced.White [Page 7]
RFC 105 RJE at UCSB March 1971Figure 1. Output Connection Op Codes--------- --------------------------Op Code (Hex) Name Explanation------- ---- ----------- 00 End-of-File. All output from the job has been transmitted (follows last op-code-x'01' logical record). 01 Output. The text field contains one record of one SYSOUT data set generated by the job. 02 Output file purged. Output from the job has been purged as requested. 03 No core for buffer. Insufficient main storage is available for transmitting output from the job. The transmission request has been aborted and the purge request (if any) has been suppressed. 04 I/O Error reading An irrecoverable I/O error was file. encountered reading the output file. The transmission request has been aborted and the purge request (if any) suppressed. 05 I/O Error purging An irrecoverable I/O error was file. encountered purging the output file. The purge request was aborted. 06 No queue space for Output from the job was not available request. and the wait-for-output option was specified, but RJOR's resources were insufficient to queue the request, which was suppressed. 07 Waiting for output. Output from the job is not available and the wait-for-output option was specified. RJOR is waiting for the job's output. 08 Canceled request not The user requested that a previously found. made request specifying the wait-for-output option be canceled. No such request was found by RJOR. 09 Request canceled. At the user's request, a previously made request specifying the wait-for-output option has been canceled. 0A I/O Error seeking An irrecoverable I/O error was file. encountered attempting to locate output from the job. The user's request wasWhite [Page 8]
RFC 105 RJE at UCSB March 1971 aborted. 0B Output not found. Output from the job was not found. The wait-for-output option was not specified by the user. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Randy Dunlap 4/97 ]White [Page 9]
[8]ページ先頭