z/OS Job Dependencies

Any job in TA can depend upon a z/OS job. If you have licensed the z/OS Gateway Adapter and have installed the z/OS software, you can add a z/OS JES dependency to a job defined in TA.

z/OS Job Dependency Definition

The z/OS JES Dependency Definition dialog is displayed from the Dependencies tab of the job’s definition in TA by clicking Add and selecting Add z/OS JES Dependency from the displayed menu.

To create a z/OS JES dependency:

Click the z/OS Gateway Adapter field. and then click the appropriate Gateway adapter that is connected to the z/OS mainframe machine that is running the z/OS job you are interested in.

Note: Each z/OS machine requires its own Gateway adapter, so choose the machine you are interested in.
Click the JES Job Name field and enter the name of the job running on the selected z/OS machine that you wish to use as a dependency.
Specify a job occurrence in the Job Occurrence section.

Since the JES job you choose could run multiple times during the day, you must specify which job occurrence you are interested in.
- First – Choose this option if the first instance of the job in the production day should be used to satisfy the job dependency.
- Latest – Choose this option if the most recent occurrence of the job should be used to satisfy the job dependency.
- Match – Choose this option if the jobs (predecessor and successor) repeat within a day, and the instance of the job dependency should match the instance of the job depending on it. If the job does not repeat, the first instance of job dependency is used.
- Specific – Choose this option to use a specific job instance. Enter a number or use the arrow buttons to denote which instance of the repeating job instances should be used.
  
  Offset – Choose this option to specify the number of job instances to offset from the instance of the dependent job. Enter a number or use the arrow buttons to enter how many job instances to offset. A positive number adds the specified number from the dependent jobs’s instance number. A negative number subtracts the specified number of job occurrences from the dependent jobs’s instance number.
Choose Ignore if questionable option if any instance number of a job that the Gateway did not track from the start of the production day is considered questionable because the Gateway cannot verify that the job did not run before the Gateway started tracking it. This might occur if the Gateway is not running at some point during the production day or if the job is not registered with the Gateway at the start of the production day.

Choose this option if the dependency is critical to a specific instance of the job and there is any uncertainty about the exact instance number. The dependency cannot be met during the day if the z/OS job instance number is questionable.
Navigate to the Dependency Condition list and specify the condition of the JES job or one of the job steps that comprise the job that will signal that the dependency is satisfied.

The condition is based on the state or status of the JES job or job step. A variety of conditions can denote a satisfied dependency. These options are available:
- Job (or Step) Completed – The dependency is satisfied when the job completes, or a specified job step has completed with the a condition code within the range of condition codes specified in the Condition Code Range field.
- Highest Condition Code – The dependency is satisfied only when the job completes with the highest code within the range of condition codes specified in the Condition Code Range field.
- Any Step Condition Code – This dependency is satisfied whenever any job step within the z/OS job completes with a condition code within the specified range in the Condition Code Range field.
- Job Started – The dependency is satisfied if the job or job step starts.
- Job (or Step) Abended – The dependency is satisfied if the job or job step results in a system or user abend.
- Job Flushed (JCL/Alloc Errors) – The dependency is satisfied whenever the job fails to start.
- Job (or Step) Canceled (by SMF Exit) – The dependency is satisfied whenever a job or job step is cancelled.
- Job Abended due to Condition Code – The dependency is satisfied whenever the job completes with an abend condition based on condition code handling.
Enter the name of the job step in the Optional (PROC.) Step field if you wish to specify a particular step within the job.

The dependency that was specified in the Dependency Condition field will apply only to the job step you specify here. The condition of any other job steps or the overall job is irrelevant once this field is used. You can include a PROC prefix, if necessary.

When desired to monitor steps in a Procedure or a procedure execution, the definitions apply:
- STEP = step name in procedure, if no step name in procedure, then null returned for STEP.
- PROC = step in JCL invoking procedure (in monitored JOB) - if no step name on invoking step, then PROC will be null.
  
  If there is no step name in the procedure, this can still be specifically triggered by providing the step name of the line invoking the procedure as PROC with '.' (PROCSTEP.) in the 'Optional [PROC.]STEP' field.
  
  If the procedure is multi-step, but only invoked once in JOB being monitored, then you only need to provide STEP name from procedure. No step name will be required on JCL line invoking procedure, but a step name will be required in the procedure.
  
  Here STEP01 is a step name in the procedure that is being invoked from the monitored JOB.
  
  If procedure is multi-step and invoked more than once in monitored JOB, then you will need to provide the step name of the JCL line invoking the procedure that you are interested in as the PROC in the dependency definition (<procstepname>.<step name in Proc> or just <procstepname>. ).
  
  Here PROCSTEP is the step name in the JCL of the monitored JOB which is invoking the procedure and STEP01 is the step name in the procedure.
  
  Here PROCSTEP is the step name in the JCL of the monitored JOB which is invoking the procedure. The period ‘.’ is required.
  
  Note: The above syntax only works if there is only 1 procedure call in the monitored job.
  
  Example: Monitored JOB:
  
  000001 //DEMOPROC JOB (20,FB3),IBMUSER,MSGLEVEL=(1,1),
  
  000002 // CLASS=A,MSGCLASS=H,NOTIFY=&SYSUID,REGION=1M
  
  000003 //PROCTST PROC
  
  000004 //STEP01 EXEC PGM=IEFBR14
  
  000005 //STEP02 EXEC PGM=IEFBR14
  
  000006 //STEP03 EXEC PGM=IEFBR14
  
  000007 // PEND
  
  000008 //*********************************************************************/
  
  000011 //PROCSTEP EXEC PROCTST
  
  000012 //PROCSTP2 EXEC PROCTST
  
  000013 //PROCSTP3 EXEC PROCTST
  
  000014 //
Set the condition code in the Condition Code Range section that signals that the dependency is true.

You can use a specific number or enter a range of numbers so that anything within the given range means that the dependency is satisfied. The condition code can range from 0 to 4095. This text field only applies if you selected these dependency condition options:
- Job (or step completed)
- Highest Condition Code
- Any Step Condition Code
- Job Abended due to Condition Code
Choose Include Abend to Abend status to the specified condition code options. If a job or job step either completes inside the specified range of condition codes or completes with an Abend status, then the job dependency is satisfied.

Monitoring Started Tasks as a Dependency

Normally, only JES jobs can be designated as z/OS dependencies but a special procedure allows Started Tasks to also act as a job dependency. To monitor Started Tasks as a job dependency, specify the Started Task name in the JES Job Name field in the z/OS JES Dependency Definition dialog.

The job names that are to be monitored as Started Tasks must be listed in the master.props file in a parameter called GWStartedTaskPrefix.

To designate Started Tasks for dependency consideration:

Open the master.props file that is located in the config directory in the master files installed on the master machine.
Type GWStartedTaskPrefix= on a new line.

Note: After the equals sign, list either the complete name or just a prefix of a Started Task name. The prefix, which can be from one to eight characters in length, will work like a job mask so that multiple jobs will match the criteria.

Note: After the equals sign, list the beginning characters that would uniquely identify the job names that should be monitored as Started Tasks. These character strings can be from one to eight characters in length (prefix or entire job name) and are separated by commas. If the characters specified in the list match the beginning characters of the job name specified in the z/OS JES dependency, it will be monitored as a Started Task (except as specified below).
To make it easier to specify common prefixes which apply to most Started Task names, another parameter provides the ability to exclude some job names which may meet the criteria defined in the GWStartedTaskPrefix parameter but are not Started Tasks. To exclude these jobs that are not Started Tasks, list the exception names (or enough beginning characters to uniquely identify the exception names) in a different parameter, GWStartedTaskExclude. Follow the same procedure to create the GWStartedTaskExclude parameter as described in steps 1-3 except name the parameter GWStartedTaskExclude.