1. A job that uses a tape for input and/or output requires that the operator mount the tape.
2. Jobs with TYPRUN=HOLD coded on the JOB statement are held by the system and scheduled by the operations staff according to the resource requirements of the job. These requirements should be given on the MESSAGE statement. See section 7.2.4 for an explanation of types of jobs that should include a MESSAGE statement and TYPRUN=HOLD on the JOB statement. Jobs requiring setups are scheduled within their respective class according to priority and resource availability. The priority for a setup job is assigned in the same manner as for non-setup jobs, i.e., by the CPU time requested. Setup and non-setup jobs compete equally by priority for selection for execution. However, setup jobs may be delayed by the lack of system resources, such as an available tape drive.
1. Job identification a. Jobname b. Production/debugging status c. Job/jobstream distinction d. Name and phone number of persons responsible for jobUsers should complete peripheral procedures such as acquiring an alien tape label before submitting their jobs.
2. Job characteristics a. Estimated time (CPU and elapsed) b. Number of tape drives to be used at one time c. Other resources
3. Extraordinary requirements a. Special forms b. Large printed outputs c. Microfiche processing d. Publication-quality output
4. Completion deadline
5. Restrictions on jobs running concurrently
6. Other pertinent aspects of the job
1. a temporary tape or MVS disk data set that is released at the end of
the job's execution
2. a permanent tape or MVS disk data set
3. a temporary disk data set that is plotted on the CalComp plotter
(standard plots)
4. a temporary tape data set that is plotted on the CalComp plotter
(nonstandard plots)
5. a system output (sysout) data set on a special
disk pack, called the spool
pack, where it is
` held for access from CMS or TSO and then purged or released for
printing on a hardcopy device; or
` transmitted to CMS, VAX/VMS, UTKUX1, or TSO; or
` sent directly to the appropriate hardcopy device.
Output from a job can be assigned in two ways: by specifying a
specific device such as tape or disk using the UNIT parameter of the DD
statement or by specifying an output class using the SYSOUT parameter of
the DD statement.
Chapter 10 describes the use of tape data sets;
Chapter 11 describes the use of disk data sets.
At UTCC output classes are used for output going to
the line printer or the laser printer.
The formats of the SYSOUT parameter
are given below.
SYSOUT=class
SYSOUT=(class,,form-name)
SYSOUT=*
where "class" may be A, H, D or *. SYSOUT=A specifies the line printer. SYSOUT=H or SYSOUT=D specifies that line printer output is to be held for review with the STAT command in CMS (see section 4.24.2.2) or the SDSF command in TSO (see section 6.3.1). The default is SYSOUT=A; however, UTCC recommends using SYSOUT=* when possible. SYSOUT=* will cause the data set to default to the class coded in the MSGCLASS parameter on the MVS JOB statement (see section 7.2.1). The "form-name" is the four-digit forms number of the form to be used when printing the data set (see section 9.1.1.1 for list of forms available).
A. Leading separator page B. JES2 news (optional) C. JES2 job log (optional) D. JCL converter output E. Job scheduler output F. Program sysout (if any) G. Trailing separator page
Separator pages The separator pages produced for each standard output unit mark the beginning and end of each job and contain job processing and distribution information. The jobname, station-id, delivery-id, and delivery-name are taken from information specified on the JOB, JOBPARM and ROUTE statements in the MVS JCL.
JES2 news Information which is of special importance to current users is printed in the JES2 news. The JES2 news appears only in the print unit containing the output with attributes specified on the JES2 JOBPARM statement. Output with other attributes such as special forms does not contain the JES2 news. If no notices are current or if the NONEWS parameter is coded on the UTPARM statement, there is no JES2 news. Several kinds of notices may appear in the JES2 news. Some of them are:
` Notices of the availability of new services and/or equipment
` Warnings of (planned) shutdowns at other than the usual times
` Changes of schedules
` Notification of any unexpected, critical restrictions due to
system bugs and the removal of such restrictions.
JES2 job log The JES2 job log is a printed copy of all communications between the system and the operator which pertain to the execution of the job. This is made available to the user unless suppressed by the NOLOG parameter on the JOBPARM statement. The heading of the job log gives the system identification and network node. Take for example the following heading:
JES2 JOB LOG -- SYSTEM E190 -- NODE UTKMVS1
In the four-character sequence E190, the first position (E) identifies the operating system (MVS/ESA), the second position the CPU number (#1), and the last two positions the CPU identification (IBM 3090). "UTKMVS1" is the network node name for this CPU. Each item in the job log is prefixed by a time stamp giving the time of day when the message was generated, the word "JOB," and the MVS job number. (Note: The time stamps are expressed in military time, i.e., 00:00:00 is midnight.) The text is always presented in the same sequence in which it was written and can consist of one or more kinds of messages as described below:
` RACF (Resource Access Control Facility)-generated messages can be identified by the presence of an "ICH" prefix before the message number. At least one RACF message will be printed with every job, telling the last time your userid accessed the MVS system. RACF will also suggest you change your password if it is more than 30 days old.
` JES2-generated messages to the operator will have a dollar sign before the message identification. Two such messages are always present, one indicating the start of execution and the other indicating its end. Other such messages may explain why the job was cancelled, e.g., excessive printed output.
` Messages generated by the operating system during the execution of the job. These can be recognized by the presence of a message number before the actual text. Explanations of these messages may be found in MVS/ESA System Messages, Volumes 1 and 2 , GC28-1812 and GC28-1813. For an explanation of messages whose numbers are of the form IECTMSx or UNTxxx, see Appendix A.
` Messages generated by the job itself. Since these messages are under the programmer's control, they do not have fixed form and must be and interpreted by the programmer.
` Operator responses to WTOR (Write To Operator with Reply) messages are also included in the job log.
` Messages from the operator to the programmer begin with the words "MSG FROM OPER:". The operator sending the message will usually initial it. The job log should be checked if any exceptional conditions occurred during execution because the log may reveal the reason for the incorrect operation of a job. The job log may also show the inefficient use of a device such as several mount-dismount cycles for the same tape during a job. The last section of the job log contains the JES2 job statistics. This section gives the following data:
` Job execution date
` Number of cards read
` Number of print records generated in JES2 queues by the job
(represents only one job level copy of the output)
` Number of punch records generated in JES2 queues by the job
(represents only one job level copy of the output)
` Number of bytes of data (print and punch) generated in the
JES2 queues by the job (represents only one job level copy of the
output)
` Number of minutes of elapsed execution time
The job log appears only in the standard print unit.
JCL converter output The JCL statements--with the exception of the JOB, JES2, comment, and procedure statements--are printed exactly as read by the system. The JOB statement is modified by the insertion of the word "JOB" and the JES2 job number in columns 73-80. Also, the RACF password is not printed. The JES2 and comment statements are modified by replacing the slash(es) beginning the statement with asterisks. When a cataloged procedure (see chapter 12) is expanded, the JCL statements within are modified by replacing the "//" with "XX". In-stream procedure statements have the "//" replaced with "++". A procedure statement that has been overridden by the user will have the "//" replaced with "X/". An in-stream procedure that has been overridden by the user will have the "//" replaced with "+/". Each JCL statement is given a number in the left margin, which will be used in the following section to reference statements to which messages are applied.
Job scheduler output If MSGLEVEL=(1,1) is coded on the JOB statement, job scheduler output is printed in the following order:
PROCLIB substitution messages (IEF653I messages)
RACF messages repeated from the job log
Messages concerning each job step including
Allocation messages for this step (IEF237I messages)
Condition code for this step (IEF142I)
Deallocation messages for this step (IEF285I messages)
EXCPs by DDNAME (UNT531I messages)
Step Statistics (UNT501I-UNT510I messages)
Starting and ending wallclock time (hh:mm:ss)
Elapsed time (hh:mm:ss)
Region requested (in Kilobytes)
Region used -- not billed to user
Region limit -- region requested + 64K
System area used -- not billed to user
TCB time in seconds -- CPU time billed to user
SRB time in seconds -- CPU time not billed to user
CPU time -- TCB time multiplied by rate
VF time -- vector facility time used
Kilobyte-hours -- computed according to formula in UTCC Schedule of Charges
KBHOURS -- not billed to user
DCT -- device connect time by device type and total
EXCPs by device type and total
EXCP cost by device type and total
Job statistics (UNT521I-UNT530I messages) -- totals for all steps
The default value for MSGLEVEL is MSGLEVEL=(2,0), which causes only
the RACF messages and the step and job
statistics to be printed.
The system messages for each step are generally prefixed by a message
number corresponding to a message in
MVS/ESA System Messages, Volumes 1 and 2
,
GC28-1812 and GC28-1813.
These messages describe the results of symbolic
parameter substitution, error conditions, and the fixup (if any)
taken. For example, the system may make substitutions
for illegal disposition
parameters.
The text for
the messages prefixed by a message
number of the form IECTMSx, or UNTxxxI are described in
Appendix A.
The allocation and deallocation messages describe the handling of the
data sets used by the job step. The allocation messages map the DD
statements onto the available I/O devices, and the deallocation
messages describe the
made of the data sets at the end of
the step.
If a DD statement is concatenated with a previous DD statement, the
allocation message for the concatenated DD statement will show a DD
name of blanks; if more than one unit is assigned to a single DD
statement, an allocation line will be generated for each unit so
assigned.
In the step accounting data,
the elapsed
(wall clock) time for a job step represents the period between the
beginning of the
actual execution of the job step and the completion of
all termination processing for it. This information does not affect
the billing since the job may be delayed by any of several external
reasons not under the control of the programmer.
Two CPU times are reported: TCB (Task Control Block) and SRB (System
Request Block) CPU time. The TCB time represents the total
amount of time
spent by the CPU in the execution of the job step, including the vector
facility time, if used.
If the vector facility is being used, the VF time is reported below the
TCB time.
The SRB time is
the time spent on behalf of the step by the system.
The "REGION USED"
figure is the amount of storage actually used during execution of the job
step. The "SYS AREA USED" is the storage used by the system in
behalf of the step.
Because the TCB time
is under the control of the programmer, along with the number of EXCPs,
they are the basis for billing. There is no charge for SRB time,
"REGION USED" or "SYS AREA USED."
Kilobyte-hours are determined according to the formula in
the UTCC Schedule of Charges, U01-0562, available through the PRTDOC
facility.
The next line shows the number of tape and disk EXCPs
charged to the user. Each EXCP represents a request for the reading or
writing of a block of data on a tape or disk. Since excessive use of
tape and disk can adversely affect system performance, this figure is
listed to allow users to determine which jobs are performing extra I/O
functions.
The next line lists DCT, device connect time, which is I/O time spent
actually transferring data. Figures are given for device type and total.
At the end of the scheduler output, a similar set of data is
printed displaying the data for the entire job, starting
and ending wall clock times and the total CPU time. The interpretation
of this line is the same as for the step accounting data line.
The displayed computing costs are estimates of the value of computing
services rather than the exact costs billed to the user's department.
The estimates are based on the standard 3-code (sponsored research)
schedule of charges. The actual charges billed by the automatic
transfer of funds to UTCC each month are those represented by the
departmental project summaries and
accompanying audit trails. The
actual charges may differ from the estimates because they are not
adjusted for reductions from indirect funding. Users are not billed
for charges assumed by
UTK
for unsponsored research and classwork.
Program output Output from the various steps of a job is printed in the order in which the steps were executed. Within a step, the output for each DD SYSOUT statement is segregated from the output for the other DD statements. That is, output for each DD statement is printed as a distinct entity, regardless of the order in which output instructions are executed by the program. If one or more DD statements contain the COPIES parameter, the multiple copies are printed consecutively.
//SAMPLE JOB ,SMITH,GROUP=J999991,USER=P999998, // PASSWORD=? /*JOBPARM COPIES=2 //S1 EXEC procname //DD1 DD SYSOUT=* //DD2 DD SYSOUT=*,COPIES=3In this case, the output would appear as follows:
separator (header)
on JES2 news, JCL, etc.
standard output for DD1
greenbar first output for DD2
second output for DD2
third output for DD2
separator (trailer)
The above sequence would appear two separate times on standard forms
since two copies were specified on the JOBPARM statement. Thus, a
total of six
would be produced for DD2. Now consider another
example:
//SAMPLE JOB ,JONES,GROUP=J999991,USER=P999998, // PASSWORD=? /*JOBPARM COPIES=2 //S1 EXEC procname //DD1 DD SYSOUT=*,COPIES=3 //DD2 DD SYSOUT=(*,,0426),COPIES=2In this case, the output would appear as follows:
separator (header)
on JES2 news, JCL, etc.
standard first output for DD1
greenbar second output for DD1
third output for DD1
separator (trailer)
on separator (header)
0426 first output for DD2
forms second output for DD2
separator (trailer)
Each of the above sequences would be produced twice, since two copies
were specified on the JOBPARM statement. Thus, a total of six copies
of DD1 would be produced on standard forms and a total of four copies
would be produced for DD2 on 0426 forms.
When a single job is broken into multiple print units for printing
due to various special forms, it is not possible in general to know
which print unit will print first. Typically, the standard
output will appear first. However, this may not always be the case.
Whenever the execution of a single job creates multiple print
units, the separate print units are returned to the user as separate
entities; no attempt is made to wait for all output for a job to
return the output in a single bundle. Users should be aware of this
fact and carefully consider the characteristics of their jobs before
declaring a missing portion of output to be "lost."
1) columns 1 and 2 contain slashes (//)
2) a forward scan from column 3 detects a blank before column 68
3) a forward scan from that blank encounters a non-blank character before column 69
4) that non-blank character is the start of the character string "JOB"
5) at least one blank follows the character string "JOB" If no statement in a user's job meets all of the above requirements, there will be no output of any kind for the job. If any statement does meet them, there will always be some printed output. If the system fails during the printing of a job, the printing is automatically resumed when the system is restarted. In this case, the leading separator page for the second output will show 'CONT' instead of 'START' for the job, and printing will resume up to five pages prior to the last line printed before the failure. The user is not charged for the extra lines written as a result of this repeated output. If the user has specified LINECT=0 on the JOBPARM statement and has no page skips in the output, printing will restart up to 300 lines prior to the last line printed before the failure. The user is not charged for the repeated output in this case either. JES2 attempts to produce all hardcopy output for jobs in execution at the time of a system failure. However, certain errors are so catastrophic that no recovery of output is possible. For example, JES2 cannot recover from severe disk errors on the disk pack used for spooling. The recovery of hardcopy output after system failure is limited to lines or statements which have actually been written to the spool pack; any lines or statements still in buffers in main memory are lost. As many as ten to thirty lines of output may be lost in most cases.
` /*ROUTE PRINT nodename.userid
The /*ROUTE PRINT statement affects all the job's output.
` //ddname OUTPUT DEST=nodename.userid` //ddname DD SYSOUT=x, // DEST=(nodename,userid)
The DEST parameter on the OUTPUT and DD statements affects only specific sysout data sets (see sections 7.2.9 and 7.2.10).
Note the use of a comma to separate the nodename and userid in the DEST= keyword on the DD statement above rather than a period as in the other statements. A SYSOUT class on the DD statement should be chosen as appropriate for the data type (A or H for print data; B or I for card-image data). The MVS/JES2 system separates sysout data into hardcopy sysout and network sysout for queueing and routing purposes. Hardcopy sysout data is routed for generation on printers connected to the local system or node (such as RMT0 or RMT8). Network sysout data is routed for transmission to another computer or node. Hardcopy and network records are counted against the LINES= and CARDS= keyword value limits established on the /*JOBPARM control statement.
Node Name Host SystemIf an invalid node name is specified, the job will fail and MVS/JES2 will respond with a JCL error message. The userid specified in JCL destination values is not checked until the data arrives at the destination host system. Data routed to invalid userids will be discarded by the destination node. Refer to MVS/ESA JCL User's Guide for further information about the JCL statements that support NJE SYSOUT data transmission via the node name and userid value specifications.UTKMVS1 IBM 3090: MVS/JES2 system (This host is the local node) UTKVM1 IBM 3081: VM/CMS system UTKVX VMS VAXcluster UTKUX1 Sun/SunOS (UNIX)
Also these non-UTCC sites:
UTCVM IBM 4381 at the Center for Excellence in Computing Applications, UT Chattanooga UTKCS1 UTK Computer Science Department VAX UTKCS2 UTK Computer Science Department VAX UTMEM1 UT Memphis VAX UTSIV1 UT Space Institute VAX at Tullahoma UTKSMA UTK SAMS VAX (production)
MVSPASSWORD
You will be asked to enter the current MVS password. Then, enter a new password and re-enter it for verification. An MVS password must be 6 to 8 characters in length, consisting of alphanumeric and/or national (#$@) characters. The MVS Resource Access Control Facility (RACF) keeps a record in encrypted form of a user's last five passwords. When the password is changed, it cannot be changed to any of these last five values. For online help, enter the VAX command HELP MVSPASSWORD.
HSUBMIT MYPROG
sends MYPROG.JCL to the IBM machines for execution, whereas
HSUBMIT MYPROG,MYDATA.IBM
concatenates MYPROG.JCL and MYDATA.IBM and submits them as one job. To have MVS batch output routed to the VAXcluster, see section 8.10.1.
To retrieve the MVS batch output from the VAXcluster The VAX RECEIVE command is used to process incoming network files from other users. For information about this command, type HELP RECEIVE on the VAX/VMS system. The number of files shown by the RECEIVE command for any given network sysout transmission unit depends on the number of sysout data sets within the transmission unit with differing sysout attributes (class, type, form number, destination, etc.). When the data arrives at the destination node, the sysout data within a single transmission unit will be separated into different files according to data attributes. The default VAX/VMS "file-spec" assigned to files received via network sysout transmission is of the form "jobname.OUT;n". The file name defaults to the name of the MVS batch job that created the sysout data. OUT is assigned as the file extension. The file version number (n) begins at 1 and is incremented by one for each file with the same MVS job name. (Note that the VAX/VMS system limits to three the number of versions of a file that can be kept simultaneously; consequently, a user who wants to RECEIVE more than three units of sysout data from the same MVS batch job must choose a file name other than the default "jobname.OUT" or else some of the units will be lost when the VAX/VMS system discards all but the last three.)
netcopy job@utkmvs1 if=filename device=punch width=80
where "filename" is the name of the input file on UNIX. The file submitted must contain unnumbered records with 80 or fewer characters per record; those longer will be truncated to 80 characters. All JCL must be in uppercase. The first record in the file must be a valid JOB statement. To have the MVS batch output routed to your UNIX account, see section 8.10.1. You will be notified on UNIX that you have received a file and can use the rdr command to preview and receive the output file. For more information on netcopy or rdr, type man netcopy or man rdr. A job stream can be submitted from a SUN workstation using a remote shell command to UTKUX1. Because a remote shell command requires that you have authority to login to the remote host, you will need a UTKUX1 account to submit jobs using the netcopy command.
rsh utkux1 -l ux1userid /usr/local/bin/netcopy if=filename device=punch
"Filename" is the name of the UNIX input file, and "ux1userid" is the userid on UTKUX1.