JOB statement to mark the beginning of a job and to tell the system how to process the job. Also, when jobs are stacked in the input stream, the JOB statement marks the end of the preceding job.
Syntax:
//jobname JOB positional-parameters[,keyword-parameter]... [comments] |
The parameters you can specify for job processing are listed below. Also we provided explanation for some of the important parameters.
Accounting information Parameter:
The value that you code for job accounting information depends on the guidelines set at your company. The value is usually a number that identifies a department or person to whom processor time is billed.
Job accounting information may consist of multiple pieces of information, not just a single value as shown in this example.
Example 1
//JOB43 JOB D548-8686 |
Example 2
//JOB44 JOB (D548-8686,'12/8/85',PGMBIN) |
Because this statement contains an account-number plus additional accounting-information, parentheses are required.
Example 3
//JOB45 JOB (CFH1,2G14,15,,,,2) |
This statement shows a JES2 accounting information parameter: programmer’s accounting number, CFH1; room number, 2G14; estimated job time, 15 minutes; and copies, 2. Parentheses are required. Standard values are assumed for the other JES2 subparameters.
CLASS Parameter:
Use the CLASS parameter if your company uses classes to group jobs. Grouping jobs helps to:
Because jobs classes are site-specific, you have to check with your operations department to determine which job classes are available for use.
Syntax:
CLASS=0 to 9 | A to Z |
Example:
//SETUP JOB 1249,SMITH,CLASS=M |
This statement assigns the job to class M.
COND Parameter:
A COND parameter can be coded in the JOB or EXEC statement of JCL. It is a test on the return code of the preceding job steps. If the test is evaluated to be true, the current job step execution is bypassed. Bypassing is just omission of the job step and not an abnormal termination. There can be at most eight conditions combined in a single test.
Syntax:
COND=((code,operator)[,(code,operator)]...) |
Example 1
//TYPE JOB (611,402),BOURNE,COND=(7,LT) |
The COND parameter specifies that if 7 is less than the return code, the system terminates the job. Any return code less than or equal to 7 allows the job to continue.
Example 2
//TEST JOB 501,BAXTER,COND=((20,GE),(30,LT)) |
The COND parameter specifies that if 20 is greater than or equal to the return code or if 30 is less than the return code, the system terminates the job. Any code of 21 through 30 allows the job to continue.
MSGCLASS Parameter:
You can use the MSGCLASS keyword parameter to assign an output class for your output listing (SYSOUT). Output classes are defined by the installation to designate unit record devices, such as printers.
MSGCLASS parameters have default settings, depending on your company's guidelines. The operating system uses the default setting if you omit this parameters from the JOB statement. In this case, you would code these parameters only if you want to have a different message class than the preset values.
Syntax:
MSGCLASS=CLASS |
Example 1
//EXMP1 JOB ,GEORGE,MSGCLASS=F |
In this example, the JOB statement specifies output class F for the job log.
Example 2
//EXMP2 JOB ,MENTLE,MSGLEVEL=(2,0) |
This JOB statement does not specify an output class. In this case, the output class defaults to the installation default output class for the device from which the job was submitted.
Example 3
//A1403 JOB ,BLACK,MSGCLASS=L //STEP1 EXEC PGM=PRINT //OUTDD1 DD SYSOUT=L |
In this example, the JOB statement and sysout DD statement OUTDD1 both specify the same output class. Consequently, the job log and data set OUTDD1 are written on the same output listing.
Example 4
//B209 JOB ,WHITE,MSGCLASS=M //STEPA EXEC PGM=PRINT //OUTDDX DD SYSOUT=* |
In this example, the JOB statement specifies that the system route the job log to output class M. The system also routes sysout data set OUTDDX to class M because SYSOUT=* is specified.
MSGLEVEL Parameter:
The MSGLEVEL parameter controls how the JCL, allocation messages, and termination messages are printed in the job's output listing (SYSOUT).
Syntax:
MSGLEVEL=([statements][,messages]) |
The MSGLEVEL parameter value consists of two subparameters:
statement The statement subparameter indicates which job control statements the system is to print on the job log.
messages The messages subparameter indicates which messages the system is to print on the job log.
MSGLEVEL have default settings, depending on your company's guidelines. The operating system uses the default setting if you omit this parameters from the JOB statement. In this case, you would code these parameters only if you want to have a different message level than the preset values.
Example 1
//EXMP3 JOB ,GEORGE,MSGLEVEL=(2,1) |
In this example, the JOB statement requests that the system print JCL statements, JCL messages, JES and operator messages, and SMS messages.
Example 2
//EXMP4 JOB ,MENTLE,MSGLEVEL=0 |
In this example, the JOB statement requests that the system print the JOB statement and any comments and JECL statements up to the first EXEC statement; and, that JES is to use the installation default for messages.
Example 3
//EXMP5 JOB ,MIKE,MSGLEVEL=(,0) |
In this example, the JOB statement requests that JES use the installation default for printing JCL statements and the system is not to print JES and operator messages unless the job abnormally terminates. SMS messages are printed only if SMS fails the job.
NOTIFY Parameter:
The system sends the success or failure message (Maximum Condition Code) to the user specified in this parameter. Following is the syntax:
NOTIFY="userid | &SYSUID" |
Here system sends the message to the user "userid" but if we use NOTIFY = &SYSUID, then the message is sent to the user submitting the JCL.
Example 1
//SIGN JOB ,TKLOMP,NOTIFY=USERID |
When the job SIGN completes processing, the system sends a message to user USERID.
Example 1
//SIGN JOB ,TKLOMP,NOTIFY=&SYSUID |
When the job SIGN completes processing, the system sends a message to the user submitting the JCL.
Programmer’s name Parameter:
The programmer name identifies the person or group responsible for a job. The programmer's name is not a mandatory part of the JOB statement unless your company has made it so.
Place the programmer’s name parameter immediately after the accounting information parameter and before all keyword parameters.
The name contains special characters (including blanks), other than hyphens, leading periods, or embedded periods.
Example 1
//APP JOB ,G.M.HILL |
This JOB statement specifies a programmer’s name with no accounting information. The leading comma may be optional; check with your installation.
Example 2
//DELTA JOB 'T.O''NEILL' |
The programmer’s name contains special characters. The installation requires no accounting information. The imbedded apostrophe is coded as two consecutive apostrophes; the entire name must be enclosed in apostrophes.
Example 3
//#308 JOB (846349,GROUP12),MATTHEW |
This JOB statement specifies an account number, additional accounting information, and a programmer’s name.
Example 4
//JOBA JOB 'DEPT. 15E' |
This installation requires the department number in the programmer’s name parameter.
REGION Parameter:
Specifies the address space required to run a job step within the job. Following is the syntax:
REGION=valueK | valueM |
Here, region can be specified as valueK or n=valueM where value is a number, K is kilobyte and M is Megabyte.
When REGION = 0K or 0M, largest address space is provided for execution.In critical applications, coding of 0K or 0M is prohibited to avoid wasting the address space.
Example 1
//ACCT1 JOB A23,SMITH,REGION=100K,ADDRSPC=REAL |
This JOB statement indicates that the job requires 100K of central storage.
Example 2
//ACCT5 JOB 178,SRI,REGION=0K |
This JOB statement indicates that the job requires largest address space is provided for execution
Example 3
//ACCT4 JOB 175,FRED,REGION=250K |
This JOB statement indicates that the job requires 250K of virtual storage. When the ADDRSPC parameter is omitted, the system defaults to ADDRSPC=VIRT.
RESTART Parameter:
The RESTART parameter to indicate the step, procedure step, or checkpoint at which the system is to restart a job.
RESTART = [stepname] [stepname.procstepname] |
Example 1
//LINES JOB '1/17/95',RESTART=COUNT |
This JOB statement indicates that the system is to restart execution at the beginning of the job step named COUNT.
Example 2
//CLIP5 JOB ,COLLINS,RESTART=PAY.WEEKLY |
This JOB statement indicates that the system is to restart execution at the procedure step WEEKLY.PAY is the name field on the EXEC statement that calls the cataloged procedure that contains procedure step WEEKLY.
TIME Parameter:
Use the TIME parameter to specify the maximum amount of time that a job may use the processor or to find out through messages how much processor time a job used. Using the TIME parameter prevents an error in your program from causing it to run longer than necessary.
TIME=(mm, ss) or TIME=ss |
Where mm = minutes and ss = seconds
You can use the TIME parameter on a JOB statement to decrease the amount of processor time available to a job or job step below the default value. You cannot use the TIME parameter on a JOB statement to increase the amount of time available.
Every job step has a time limit. If you do not specify a TIME parameter on the JOB statement, the time limit for each job step is:
If you specify a value other than TIME=NOLIMIT or TIME=1440, SMF uses its current job wait time limit.
Example 1
//IBMUSER JOB IBMTEST,TIME=(10,15) |
This statement specifies that the maximum amount of time the job can use the processor is 10 minutes, 15 seconds.
Example 2
//IBMUSER JOB IBMTEST,TIME=(,20) |
This statement specifies that the maximum amount of time the job can use the processor is 20 seconds.
Example 3
//IBMUSER JOB IBMTEST,TIME=4 |
This statement specifies that the maximum amount of time the job can use the processor is 4 minutes.
Example 4
//IBMUSER JOB IBMTEST,TIME=NOLIMIT |
This statement specifies an unlimited amount of time for job execution. the job can use the processor and remain in wait state for an unspecified period of time. The system will issue messages telling how much processor time the job used.
Example 5
//FIRST JOB ,SMITH,TIME=2
//STEP1 EXEC PGM=READER,TIME=1
.
.
.
//STEP2 EXEC PGM=WRITER,TIME=1
. |
In this example, the job is allowed 2 minutes for execution and each step is allowed 1 minute. If either step continues executing beyond 1 minute, the entire job abnormally terminates beginning with that step.
Example 6
//SECOND JOB ,JONES,TIME=3
//STEP1 EXEC PGM=ADDER,TIME=2
.
.
.
//STEP2 EXEC PGM=PRINT,TIME=2
. |
In this example, the job is allowed 3 minutes for execution, and each step is allowed 2 minutes. If either step continues executing beyond 2 minutes, the entire job abnormally terminates beginning with that step. If STEP1 executes for 1.74 minutes and STEP2 tries to execute beyond 1.26 minutes, the job abnormally terminates because of the 3-minute limit specified on the JOB statement.
USER Parameter:
USER parameter used to identify the User id to submit the job. The userid is used by RACF, the system resources manager (SRM), and other system components.
Syntax:
USER=[userid] |
Example
//TEST JOB 'D83,123456',USER=MYNAME,PASSWORD=ABCD |
This statement identifies the user submitting this job as MYNAME.
If you have any doubts or queries related to this chapter, get them clarified from our Mainframe experts on ibmmainframer Community!