You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Tips & Techniques > Systems Management

JES2 Job Execution Control New in z/OS 2.2


After a job group is instantiated, jobs can then be bound, or “registered,” to it via a new JCL SCHEDULE statement. Any JES2 batch job can be registered to a job group.

Job groups support three types of dependencies:

  1. Before
  2. After
  3. Concurrent

The following job group illustrates these concepts:

//*-----------------------------
//*  DEPENDENCY NETWORK:               
//*                             
//*                    JOBC        
//*                     |            
//*             JOBE===JOBA     
//*                     |          
//*                    JOBX          
//*                           
//*                          
//*-----------------------------
//MYGROUP  JOBGROUP             
//* 
//JOBA     GJOB
//*             
//JOBE     GJOB                 
//         CONCURRENT NAME=JOBA 
//*                             
//JOBC     GJOB                 
//         BEFORE NAME=JOBA     
//*                             
//JOBX     GJOB  
//         AFTER  NAME=JOBA                     
//*                               
//MYGROUP  ENDGROUP                                                      

When this JCL is submitted, JES2 will instantiate job group MYGROUP in the JES2 checkpoint. A “logging job” with the name MYGROUP will also be created. Note that no jobs have been registered to the group yet. However, to illustrate what will happen when jobs are registered:

  • JOBC will run first due to BEFORE NAME=JOBA statement.
  • Once JOBC completes, JOBE and JOBA will run concurrently (simultaneously) on the same JES2 member due to the CONCURRENT statement that ties JOBE and JOBA together.
  • Once both JOBE and JOBA complete, JOBX will run due to the JOBX statement specifying AFTER JOBA.
  • Once JOBX is complete, the job group state will change to COMPLETE. The job group will continue to exist until it is explicitly purged as a group; or until all jobs registered to it are purged, at which time the job group itself is purged.
  • The job log of the logging job MYGROUP contains messages that record key job group transitions.

The SCHEDULE JCL statement is used to associate jobs with the job group. Once the JCL for a job with a SCHEDULE statement is successfully processed the job is “registered” to the job group named on the JOBGROUP keyword. Jobs defined as part of a job group can be submitted in any order but must be submitted after the JCL of the job group (JOBGROUP and related statements) is processed and the job group definition is committed to the JES2 checkpoint.

For example, consider the following JCL. The jobs defined in the job group MYGROUP from the prior example are submitted here in an order different than the expected execution order:

//*===JOBA=====================================================
//JOBA      JOB TIME=NOLIMIT,REGION=0K,MSGCLASS=A,CLASS=B        
//          SCHEDULE JOBGROUP=MYGROUP                         
//STEP1     EXEC PGM=IEFBR14 
//*===JOBC=====================================================
//JOBC      JOB TIME=NOLIMIT,REGION=0K,MSGCLASS=A,CLASS=A 
//          SCHEDULE JOBGROUP=MYGROUP
//STEP1     EXEC PGM=IEFBR14
//*===JOBE=====================================================
//JOBE      JOB TIME=NOLIMIT,REGION=0K,MSGCLASS=A,CLASS=B        
//          SCHEDULE JOBGROUP=MYGROUP                          
//STEP1     EXEC PGM=IEFBR14                              
//*===JOBX=====================================================
//JOBX      JOB TIME=NOLIMIT,REGION=0K,MSGCLASS=A,CLASS=A        
//          SCHEDULE JOBGROUP=MYGROUP                          
//STEP1     EXEC PGM=IEFBR14                                     

As mentioned above, the job log of the job group logging job (JESMSGLG) is a central place where all job group and constituent job transitions are recorded. These transitions include job registration, execution, jobs being flushed, job completion (return) codes, etc. Here's an example of a complete job log for the MYGROUP:


                        J E S 2  J O B  L O G  --  S Y S T E M  N 1 M 1  --  N O D E  P O K

G0000062  IRR010I  USERID IBMUSER  IS ASSIGNED TO THIS JOB.  
JOB00063  $HASP1300 JOBA registered to job group MYGROUP                                            
JOB00064  $HASP1300 JOBC registered to job group MYGROUP                                            
JOB00064  $HASP1301 JOBC in job group MYGROUP queued for execution                                  
JOB00064  $HASP373 JOBC     STARTED - INIT 1    - CLASS A        - SYS N1M1                         
JOB00064  $HASP395 JOBC     ENDED - RC=0000                                                         
JOB00065  $HASP1300 JOBE registered to job group MYGROUP                                            
JOB00065  $HASP1301 Concurrent set containing job JOBE in job group MYGROUP 
                   queued for execution    
                   $HASP1201 Concurrent set containing job JOBE in job group MYGROUP                    is entering execution                                              JOB00063  $HASP373 JOBA     STARTED - WLM INIT  - SRVCLASS VEL90    - SYS N1M1                       JOB00065  $HASP373 JOBE     STARTED - WLM INIT  - SRVCLASS VEL90    - SYS N1M1                      
JOB00066  $HASP1300 JOBX registered to job group MYGROUP                                            
JOB00063  $HASP395 JOBA     ENDED - RC=0000                                                         
JOB00065  $HASP395 JOBE     ENDED - RC=0000                                                         
JOB00066  $HASP1301 JOBX in job group MYGROUP queued for execution                                  
JOB00066  $HASP373 JOBX     STARTED - INIT 1    - CLASS A        - SYS N1M1                         
JOB00066  $HASP395 JOBX     ENDED - RC=0000                                                         
G0000062  $HASP1304 job group MYGROUP is complete       

Records highlighted in red demonstrate the following facts:

  • The job identifier for a logging job starts with a G (e.g., G0000062). This job ID can be used in commands just like batch job IDs. For example, the command $DG62 will display the status of the job group MYGROUP. The job group name can also be used in commands, such as $DG’MYGROUP.’
  • Job JOBA is recognized by the job group when it is registered
  • CONCURRENT statement was used to define JOBA and JOBE as a “concurrent set”. These jobs must run together simultaneously on the same JES2 member after JOBC runs.
    HASP1201 is cut when the concurrent set (JOBE and JOBA) enters execution. z/OS Workload Manager (WLM) has extended batch initiator support to assure the set is only run on a member where capacity is available.
  • No jobs in the concurrent set can start until JOBC successfully completes its execution

Once a job group is instantiated, various operator commands can be used on the group. Some examples include:

  • $CG’MYGROUP’: Cancel a job group and all the jobs registered to it.
  • $PG’MYGROUP’: Purge a job group ( if completed ) and all jobs registered to it.
  • $HG’MYGROUP’: Hold a job group
  • $AG’MYGROUP’: Release a job group
  • $TG’MYGROUP’: Change attributes of a job group
  • $DG’MYGROUP’,SUMMARY: Display a summary of a job group
  • $DG’MYGROUP’,JOBS: Display only job information for the job group:
            $DG'MYGROUP',JOBS                                     
  G0000262  $HASP890 JOB(MYGROUP)                                 
  $HASP890 JOB(MYGROUP)   JOB GROUP JOB LIST                      
  $HASP890                JOB NAME  JOBID     JOB STAT  COMP STAT 
  $HASP890                --------  --------  --------  --------- 
  $HASP890                JOBY      JOB00269  Q=HARDCPY COMPLETE  
  $HASP890                JOBX      JOB00268  Q=HARDCPY COMPLETE  
  $HASP890                JOBC      JOB00265  Q=HARDCPY COMPLETE  
  $HASP890                JOBE      JOB00267  Q=HARDCPY COMPLETE  
  $HASP890                JOBB      JOB00264  Q=HARDCPY COMPLETE  
  $HASP890                JOBA      JOB00263  Q=HARDCPY COMPLETE  
  $HASP890                JOBD      JOB00266  Q=HARDCPY COMPLETE  

Messages are issued by the commands to indicate which actions are taken on what objects (job or job group). The $DG command has multiple keywords that provide different ways to view the state of a job group and its constituent jobs.

For individual jobs associated to a job group, the $DJ command was extended to indicate whether the job is associated with a job group, whether it has any BEFORE/AFTER dependencies with other jobs in the group, or it has execution delays resulting from its participation in a job group or a concurrent set within a job group.

Closer Look at Job Flow

We have barely scratched the surface on what JEC enables for defining job flow. The 10 new JCL statements provide the base that can be used to model extremely complex job relationships. The job log data set for the logging job shows step-by-step information on the execution flow of the jobs in the job group. And the new and enhanced commands provide the control and monitoring functions needed to maintain a smoothly running job group.

Deadline Scheduling

Associating a job to a job group is not the only function of a new SCHEDULE JCL statement. Various keywords of a SCHEDULE statement provide convenient new functions that add flexibility to the task of the job management:

  • HOLDUNTL – this keyword allows to request that the job must be in the held state until the time specified by the keyword. At that time the job is automatically released and can become eligible for execution.
  • STARTBY – this keyword allows to specify the target execution deadline for the job.
  • WITH – this keyword allows to indicate that the job must not run unless another (reference) job is active and when the job runs it must run on the same member as the reference job.

These new features can be used on their own or together with the Job Execution Control to further enhance the job scheduling capabilities of native work management on z/OS.

The next article in this series will discuss the deadline scheduling functions in more detail.

Alexei Pytel is an advisory software engineer working in z/OS JES2 development since 2007. He has been with IBM for 22 years.

Bruce Talbott is an advisory software engineer performing development for JES2 since 2007. His 15 years with IBM have included development and Level3 experience on IBM i in areas such as work management, local and remote workstations, and data communications.

Kevin Kathmann is an advisory software engineer working in JES2 development since 2008. He has worked more than 20 years with IBM.

Steve Simonson is a Senior Software engineer who has worked for IBM for 31 years and 8 years on JES2 as a developer.

Tom Wasik is the team leader in JES2 Design and Development at IBM Rochester. He has spent 28 years working on JES2 at IBM.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Optimal Service Delivery

Overcome eight key challenges and reduce costs

MAINFRAME > TIPS & TECHNIQUES > SYSTEMS MANAGEMENT

An Accurate Benchmark Is Important

Advice for the Lazy Administrator

Steps you can take to avoid late nights and system frights.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters