| z/OS Batch Jobs | ||
|---|---|---|
 |  | |
| z/OS Batch Jobs | ||
|---|---|---|
| | | |
|
Entire document Available as PDF |
Table of Contents
A job is a set of data and the instructions that tell the system what you want it to do with that data. You may perform a task interactively by submitting the instructions one at a time. A batch job is submitted to the system in its entirety, including instructions and data.
CNS's IBM mainframe uses IBM operating systems. The production operating system is z/OS (formerly known as OS/390) with JES2. When you submit a batch job to z/OS, you must use IBM Job Control Language (JCL) and Job Entry Subsystem 2 (JES2) control statements. These control statements tell z/OS or JES2 how to process your job.
There are several types of JCL and JES2 statements, ranging from quite simple to very complex statements. Some of these statements are required in every job (for example, the JOB statement). Others can be added to alter the default flow of processing. The most common of these statements and local modifications of them are described in document D0013, IBM Job Control Language Conventions at CNS. This chapter describes the default flow of a job through the system, methods of altering the flow, and possible problems relating to the submission of batch jobs.
Batch jobs can be submitted from CNS's TSO time-sharing system. The SUBMIT command in TSO sends jobs to z/OS (OS/390). Both of these commands have HELP files in their respective systems.
In addition, many of the other computer systems on campus and throughout the State University System network provide commands to submit batch jobs to CNS. To determine how to submit a job to CNS from other systems on the UF campus, refer to the local documentation for that system, or contact the consultants for that system.
When a job arrives at the z/OS (OS/390) system, the system assigns it a five-digit JES2 job number, which is associated with the job until it leaves the system. Whenever you submit a job to z/OS (OS/390), you should make a note of this number because it uniquely identifies your job, and you will need it in order to inquire about any problems which might occur during the execution of your batch job.
JES2 controls the processing of batch jobs. When a job is submitted, the userid and password are checked.
Jobs are submitted in job classes, which specify the type of job, and help determine the priority in which your job runs. Some job classes are restricted to certain account types and some resources (for example, the use of magnetic tapes) are restricted to certain job classes. JES2 checks the JCL for invalid combinations.
If your JCL passes this initial scan, JES2 places the job in a queue of jobs awaiting execution. The job's position in the queue depends upon several factors:
job class
the job's size
the amount of time the job is in the system
While some jobs are in the queue awaiting execution, their priority is periodically incremented. We call this "aging." JES2 selects for execution the job with the highest priority that can be run with available resources.
When the job finishes executing, it is placed into a queue of jobs waiting to be printed. This queue is divided into local or remote according to the destinations of the jobs in it. Priorities within this queue are determined by the amount of output for the job. Larger jobs have lower priorities and, therefore, longer waits. When the job reaches the top of the queue for its destination, the output is printed.
In addition to the output generated by the job itself, JES2 prints header and trailer pages to identify the job.
When all output for the job is completed, it is removed from the system (purged). Hardcopy output that is produced at the SSRB is filed for three days and is then recycled. Any job that remains in the system for ten days or longer will be automatically purged by the system. See the "Job Output" chapter for more information on job filing.
Once a job reaches z/OS (OS/390), you can check on its progress using the IOF command in TSO.
If you are signed on to TSO, use the job name or job number in the IOF command, which can have these forms:
IOF jobname
or
IOF * JOBID(Jnnnnn)
The CLASS= parameter on the JOB statement alters the priority at which your OS/390 batch jobs will be run and determines the rate at which the job will be charged. CLASS=A is the default job class at CNS. Class A runs at normal priority with regular rates.Note: Rates for all CNS services are listed in the CNS Charging Algorithm document (D0001).
Class A jobs that request no setups and that require two seconds of CPU time or less are automatically set to priority 14. This is a higher priority than any job can obtain through priority aging. Charges for these jobs will be billed at normal Class A rates. The execution priority schedule does not affect normal output priority. If you want fast, complete turnaround, do not request special-forms output routed to NER.R0; special-forms printing is usually held until overnight, regardless of the priority. (See DOCWEB Document D0077 for more information about special forms output.)
There are no discounts based on job class for consumption of physical resources, such as pages printed.
Jobs are assigned a priority for execution according to their job class and estimated execution time. The priority of some jobs increases at regular intervals while the job is awaiting execution. This is called priority aging. Jobs in the following classes, however, are assigned an absolute priority and do not age: Classes 5, 2, 1, and 0. The output priority for these jobs is equal to the execution priority.
For jobs other than the absolute priority jobs, the print priority is assigned based on the number of lines of output your job generates; the priority of your job decreases as the volume of output increases.
The following table shows the types of priority that are available by job class and the corresponding increase or decrease in the total charges for the job.
Table 1. Job Classes and Priorities
| Job Type | Class | Multiplication Factor or Adjustment |
|---|---|---|
| NORMAL | CLASS=A | no adjustment (default) |
| LOW | CLASS=2 | .50 |
| PRODUCTION | CLASS=P | .50 (minimum charge of $8.00/job) |
| STANDBY | CLASS=1 | .25 (minimum charge of $0.75/job) |
| VERYSLOW | CLASS=0 | .10 (minimum charge of $25.00/job) |
| RESEARCH | CLASS=R CLASS=S | Class A rates with no CPU charge (see below) .50 x Class R job charge |
| RCI | CLASS=G CLASS=H | No charge* -- 10 minute CPU limit No charge* |
| WEEKEND | CLASS=W | $500.00 flat rate (see below) |
| UTILITY | CLASS=U | No charge for CPU, I/O, or job submission |
| QUICK | CLASS=Q | No charge for I/O, job submission, or lines printed (max. 2 CPU seconds and 500 lines) |
| URGENT | CLASS=5 | 3.00 |
* for RCI participants only
Low priority jobs (Class 2) will be run at the operator's discretion when they will not interfere with the running of other jobs. In most cases, turnaround time will be no longer than overnight, but no minimum or maximum turnaround is guaranteed.
These jobs (Class P) can be defined as I/O-bound jobs. They are run in first-in/first-run order. Class P jobs receive a 50% discount and have a minimum charge of $8.00. No discount is given for the cost of pages printed.
Standby jobs (Class 1) can have a maximum of one tape setup. They will be run at the operator's discretion on nights and weekends when they are not likely to interfere with higher priority jobs. STANDBY jobs can be cancelled without notice in order to prevent degradation of services to users paying for higher priorities.
This priority (Class 0) is intended for jobs that require hours of CPU time and modest I/O. VERYSLOW priority jobs are run only during the weekend operating hours at the discretion of the Shift Supervisor. Approval must be received from the Shift Supervisor at least one day before the job is submitted. Class 0 jobs are limited to one tape setup and are billed at 10% of Class A rates, subject to a minimum charge of $25 per job.
This job class (Class R) is for CPU-intensive research computing jobs. CPU time is free under Class R, but all other charges apply at the normal Class A rates. Class R is restricted solely to research computing users, that is, for jobs running under userids for all 100..... (except 19xx.....), all 200....., all 400...., and 6032.... account numbers. No tape setups can be run under Class R, so your data and programs must be either disk resident (online) or part of your job stream. There is one Class R initiator. It will run at all times that batch processing is available, at a very low dispatching priority, to use otherwise unused CPU cycles. There is no guaranteed turnaround time.
Like Class R, Evening Research (Class S) is for CPU-intensive research computing jobs. Class S is run on weekends, holidays, and after 6:00 P.M. on weekdays. The class R charge is multiplied by .5 to determine the Class S charge. Class S limitations are the same as those for Class R.
RCI jobs (classes G and H) are reserved for special Research Computing Initiative (RCI) userids, which are provided free to qualifying SUS faculty members to support the enhancement of numerically intensive computing in higher education. Use of computing resources is restricted to the amount awarded under the RCI. No tape setup is permitted under classes G and H. Class G jobs are limited to 10 minutes CPU time.
To obtain approval for use of Class W, contact Bill Carr, Operations Manager. Class W is for research applications only and is available on weekends and holidays. Userids with jobs run under Class W will be billed a flat $500.00 for the weekend, regardless of the number of jobs run. No tape setups are allowed.
Class U is limited to certain CNS utilities such as CHRGLIST and XFER3 (funds transfer).
Class Q is limited to specific educational applications with a maximum of 2 seconds of CPU time. The SAS and SPSSQ processors are charged for CPU usage at normal Class A rates. There is no CPU charge for the ASSIST, PLC, SPITBOL, WATBOL, WATFIV, and WPASCAL processors.
These jobs (Class 5) are for fast processing. Because of the quick turnaround time, Class 5 jobs carry a 200% surcharge.
Both the execution priority and the print priority of all eligible jobs, except those in execution, are incremented by 1 once an hour. For example, if a job enters the print queue with a priority of 6 at 2 p.m., and it is still in the print queue at 3 p.m., its priority is incremented from 6 to 7.
Priority aging will affect only those jobs not in execution that have a priority from 3 through 13. LOW, STANDBY, VERYSLOW, and URGENT jobs have an absolute priority and do not age.
The execution priority of a Class A job is based on estimated execution time. As the job awaits execution, its priority ages every hour.
The following priorities are never changed while the job is in the system. LOW (Class 2) priority jobs are assigned a priority of 1, STANDBY (Class 1) and VERYSLOW (Class 0) priority jobs get a priority of 0. Those with URGENT (Class 5) priority get a priority of 14.
The following table shows how the entry priority of normal priority (Class A) jobs is computed.
Entry priorities vary for jobs with special setups that execute in two CPU seconds or less.
Priority for printing is based on the actual number of lines of output a job produces, NOT the number of lines estimated. The print priority of LOW, STANDBY, VERYSLOW, or URGENT jobs does not age, but stays at 1, 0, 0, or 14, respectively.
The following table shows how the print priority for normal priority (Class A) jobs is computed.
Job turnaround time is influenced by many factors, such as the amount of CPU time required by a job, the number and type of resources a job needs (tapes, printers, etc.), the class under which a job is run, and the system load or number of jobs in the system at one time. Because of all these variables, there is no "average" turnaround time. Also, turnaround time is typically longer at the beginning of a month, the end of an academic semester, or the end of the fiscal year. The following hints can help you improve turnaround time:
Submit your batch jobs late in the day, at nights, on weekends, or on holidays, when the demand for resources is lower.
Invest some time in desk-checking your programs before you submit them. You might be able to identify problems and not have to wait for your output to find that you left out a comma or space in your program.
Use Class Q compilers or Class U utilities whenever possible.
Analyze your program's needs and accurately estimate your CPU request in your JCL. These parameters directly affect priorities. If you can limit your CPU time to two seconds or less and your job requires no tape setups, the job will execute much sooner.
If you are going to use a program repeatedly, compile and link-edit it so you do not have to wait for it to be compiled and link-edited each time you run it.
| | | |
| z/OS: Submitting z/OS (OS/390) Batch Jobs to CNS |  | Job Output |