. Specification of for any of , , or
indicates use of the contents of the corresponding login accumulator.
'SOURCE'
Set the source accounting parameter accumulators to .
'PRINT'
Sets the print accounting parameter accumulators to .
'PUNCH'
Sets the punch accounting parameter accumulators to .
'SOURCE' ( _ )
Sets the source pathname of job to , and the source
accounting parameters to , if specified, or otherwise
to the contents of the source accounting parameter accumulators. If
job already exists and its source pathname has not been
specified, the new pathname is stored; if it has been specified, it
is changed unless source file retrieval has already begun. If the
job does not already exist, a new job is created and the pathname
stored. Restrictions are that if a job with a given has
completed processing, it must be DELETE'd before that may be
used for a new job; a user may only alter jobs owned by him; and he
may not own more than a certain fixed number of jobs (currently 5).
If the user already owns the maximum number, an attempt is made to
delete an old job to make room for the new one, as described for
INPUT under standard syntax. The SOURCE command has the following
possible error responses: 'NEW JOBS ARE NOT BEING ACCEPTED AT THIS
TIME.', 'USER ALREADY OWNS THE MAXIMUM NUMBER OF JOBS.',
'USER DOES NOT OWN JOB .', 'JOB HAS
ALREADY COMPLETED.', and 'JOB IS ALREADY BEING, OR HAS BEEN,
READ.'
'PRINT ( _ )
Sets the print pathname of job to , and the print
accounting parameters to if specified, or otherwise
to the contents of the print accounting parameter accumulators. The
PRINT command either creates a new job or modifies an existing one,
as explained under SOURCE, and has the same restrictions and error
messages listed for the SOURCE command, after making the obvious
substitution of 'PRINTED' for 'READ'. The PRINT command is valid
only before print file transfer begins.
Krilanovich [Page 12]
RFC 477 Remote Job Service at UCSB 23 May 1973
'PUNCH' ( _ )
Sets the punch pathname of job to , and the punch
accounting parameters to if specified, or otherwise
to the contents of the punch accounting parameter accumulators. The
PUNCH command either creates a new job or modifies an existing one,
like the SOURCE and PRINT commands, and has the same restrictions and
error messages listed for the SOURCE command, after making the
substitution of 'PUNCHED' for 'READ'. The PUNCH command is valid
only before punch file transfer begins.
'DELETE'
Identical in function to the CANCEL command in standard syntax.
'INPUT'
Places the job identified by in a queue within RJS of jobs
owned by the users awaiting source file transfer. When it becomes
the first or only job in this queue, the retrieval of the source file
is initiated. If the INPUT command is successful, the message 'JOB
ACCEPTED FOR PROCESSING.' is displayed. The following error
messages are possible: 'JOB NOT FOUND.', 'USER
DOES NOT OWN JOB .', 'JOB HAS ALREADY COMPLETED.', '
SOURCE PATHNAME HAS NOT BEEN SPECIFIED.' and 'PRINT PATHNAME HAS NOT
BEEN SPECIFIED.'
'JOBSTAT'
Identical in function and response to the 'STATUS' command in
standard syntax.
'JOBLIST'
Lists the jobid's of those jobs owned by the user.
$
= a string of any characters including '?' and '.'.
Note that must be CR-LF, rather than period.
Issues as a HASP operator command over the user's virtual
operator's console. See Appendix A for a description of HASP
commands and command responses.
Krilanovich [Page 13]
RFC 477 Remote Job Service at UCSB 23 May 1973
RJS File Transfer
The defined earlier is the means whereby the user
specifies the location and attributes of his source, print and punch
files. The means of determining a file's location have been
previously discussed; this section explains the controls the user has
over data attributes.
The parameter specifies the type of carriage control and
the mode of transfer. For the case of transfer over a simplex
connection, this parameter has the following meanings:
':T' or ':TE' - TELNET-like carriage control. The data is a
stream of characters with embedded carriage control bytes. Page
eject is signaled by form feed, ASCII or EBCDIC decimal 12, new
line by carriage return - line feed, ASCII l3-lO, EBCDIC 13-27.
Multiple new line ('double spacing' or 'triple spacing') is
indicated by multiple occurances of CR-LF.
':A' or ':AE' - ASA carriage control. The data is a series of
fixed-length records, 81 characters on input, 133 on output, with
the first character of each record an ASA carriage control
character. The possible carriage control characters are as
follows; '+' - no line advance before print (overprint), ' ' -
one line advance (single space), '0' - two lines advance (double
space), '-' - three lines advance (triple space), and '1' - page
eject. Whatever carriage control character appears on input is
ignored.
':N' or ':NE' - no carriage control. The data is a series of
fixed length records, 80 characters on input, 132 on output. Any
carriage control generated on output is discarded before
transmission.
When file transfer takes place by means of FTP, the interpretation of
the parameter is somewhat different. In this case the
meanings are as follows:
':T' or ':TE' - TELNET-like carriage control. The data has the
same format as for the simplex connection, and is transferred in
stream mode, file structure, and either ASCII ('A') or EBCDIC
('E') type.
':A' or ':AE' - ASA carriage control. Data is transferred in
blocked mode, record structure, and either ASCII print ('P') or
EBCDIC print ('F') type. The first character of every record is
the ASA carriage control character described above.
Krilanovich [Page 14]
RFC 477 Remote Job Service at UCSB 23 May 1973
':N' or ':NE' - no carriage control. Data is transferred in
blocked mode, record structure, and either ASCII ('A') or EBCDIC
('E') type. As for the simplex connection, no carriage control
information is present.
In order to effect the FTP file transfer, RJS issues the following
FTP commands (in the given order): USER (if access user name has
been specified), PASS (if password specified), ACCT (if account
specified), BYTE (specifying bytesize of 8), ALLO (if outputting
file), TYPE, STRU, MODE, SOCK, and APPE or RETR.
Krilanovich [Page 15]
RFC 477 Remote Job Service at UCSB 23 May 1973
Appendix A: The HASP Spooling System
HASP is a spooling-queuing-scheduling system used in conjunction with
IBM OS/360 to aid in processing of batch jobs. The main purpose of
HASP is to increase throughput by minimizing I/O wait time and
providing a priority scheduling scheme whereby shorter jobs are
chosen for processing over longer jobs.
There are several stages of processing, or functions, within HASP.
At any instant, a given job is either in some stage of processing, in
which case the job is said to be active, or it is waiting to be
processed by some function, in which case it is said to be queued for
that function. Jobs to be processed by a function are selected from
the queue of jobs waiting for that function, in order of decreasing
priority. A job's priority is determined by its estimated CPU tine
and volume of output. The result is that smaller jobs are selected
for processing over larger jobs, and therefore spend less time in the
system.
The HASP remote user is provided with a virtual operator's console.
Over this console he may enter HASP operator commands to display
information about the system in general, and to exercise control over
his terminal and his jobs. HASP sends messages to his console in
response to his commands, and to inform him of conditions concerning
him as they arise. HASP commands have the following general form:
$ ,,...,
where
= a single character verb which
identifies the general function
to be performed
= identification of the object to
be displayed or acted upon.
Zero or more operands may be present, depending on the command, and
commas are used to separate operands when more than one is used. In
general, alphabetics may be entered in either upper or lower case,
and for text outside paired apostrophes, blanks may be inserted at
any point desired. Apostrophes intended as text characters must
appear in duplicate.
Every HASP command ellicts one or more responses. The response "OK"
is used in many cases to acknowledge the command and to signify that
the requested action has been taken or initiated. In the later case,
an information message will be issued when the request is completed.
Krilanovich [Page 16]
RFC 477 Remote Job Service at UCSB 23 May 1973
Every HASP console message begins with the text 'S HH.MM.SS' or
'S*HH.MM.SS', where HH.MM.SS is the time of day in hours, minutes,
and seconds, and in 24 hour clock.
Many commands display job status information as a response. The
format of this standard response is as follows:
jobs queued for processing:
JOB jjj jobname AW EXEC class PRIO prio HOLD
PRINT rem PURGE
PUNCH rem *DUP*
PURGE
jobs being processed:
JOB jjj jobname EXECUTING class PRIO prio HOLD
ON DEVICE dev PURGE
IS PURGING
where
jjj = HASP assigned job number
jobname = OS jobname
AW = 'AWAITING'
class = job's job class
prio = job's HASP internal priority
rem = terminal number of remote terminal
where job is queued to print or punch
dev = device name
HOLD = signifies job is in hold status, or
will be at completion of current
function
PURGE = signifies job will be purged at
completion of current function
*DUP* = signifies job cannot begin execution
until another job with same jobname
completes
The following is a brief description of those HASP operator
commands that may be issued by a remote user (for a more
complete description, see NIC #16306):
SDA Display status information on all active jobs
SDF [,rem] Display number of jobs queued for special forms
SDN [,queue] Display status information on all queued jobs
SDQ Display number of queued jobs
Krilanovich [Page 17]
RFC 477 Remote Job Service at UCSB 23 May 1973
SCJ jjj Delete job immediately
SKJ jjj Issue OS CANCEL and delete job
immediately
SPJ jjj Delete job after current function
SDJ jjj Display job status information
SD'jobname Display job status information
SB device,pages Backspace device
SC device Delete current function on device
SF device,pages Forward space device
SDP device Display job number of job on device
SDI Display status and classes of initiators
SDLINE rem Display status of remote terminal
SDRM rem Display status of remote terminal
SDU Display status of local unit record
devices
SDM rem,'message' Display message to remote console
Krilanovich [Page 18]
RFC 477 Remote Job Service at UCSB 23 May 1973
Appendix B: RJS Reply ID's
The following is a list of the reply id's of the replies
generated by RJS in response to the indicated commands:
command success reply failure replies
USER 330 501
PASS 230 501,431,505
ACCT 200 501
BYE 231 501
REINIT 2O4 5O1,5O4
INUSER/INID 200 501,504
INPASS 200 501,504
INACCT 200 501,504
OUTUSER 200 501,504
OUTPASS 200 501,504
OUTACCT 200 501,504
INPATH 200 501,504
OUTPATH/OUT 200 501,504
INPUT 260 501,360,504,505
CHANGE 200 501,464,504
STATUS (no operand) 100 501
STATUS (with operand) 161 501,464,504
CANCEL 262 501,464,504
Possible spontaneous reply id's are: 300, 440, 441, 442, 461, and
466.
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Mikan Mirko]
Krilanovich [Page 19]