MAINFRAME > Tips & Techniques > Systems Management

JES2 Job Group State Transitions

JES2 Job Execution Controls
 

This is the fourth of five articles on Job Execution Control (JEC).) Read parts one, two and three here.

In z/OS V2.2, JES2 provided new support called Job Execution Controls (JEC) so that customers could have better control over the execution of related jobs from given applications by providing the job group as a mechanism for defining these sets of jobs and their relationship to each other. This article will describe the different states a job group can encounter, and what situations will trigger transitions into those states.

First, let’s present a list of the various states that can exist for a job group and a short description of each of those states. Please refer to Table 1 for definitions of terms used in this article. The states include:

  • ZOD_NOT_FND: A job group structure exists indicating the definition of a job group has been started (a JQE) but there’s no associated internal checkpoint structure (a ZOD) in existence that contains the job group definition information. This is the typical status when there’s a Job Control Language (JCL) error during job group submission.
  • PENDING: Initial state of a job group. No jobs are associated with the job group.
  • ACTIVE,INIT: One or more jobs is associated with the job group, but not all jobs are defined. Some jobs might be executing.
  • ACTIVE: All jobs are defined and associated with the job group. Normal job group operations can occur. Some jobs might be executing.
  • HELD: An operator requested that the job group be held, or the job group was submitted as held. No new jobs in the job group will be started. Some jobs might be running that were started before the job group was held, and they will be allowed to continue executing.
  • CANCELING: The operator has issued a cancel command for the job group. Jobs that are executing are canceled (using the CANCEL command) and jobs that have not started execution are canceled (flushed).
  • FLUSHING: A non-recoverable error has been encountered and the job group is being terminated. All jobs that haven’t been executed are being canceled (flushed) and the job group is waiting for executing jobs to complete. Once the execution jobs complete the job group moves to COMPLETE status.
  • SUSPENDING: A recoverable error was encountered. A subset of jobs can’t be run due to the error. Other jobs are running or are eligible to run.
  • SUSPENDED: A recoverable error was encountered, and all jobs that are eligible to run have been run. There are no jobs that are currently running in the job group. Resubmit corrected jobs for those marked with an INERROR status so the job group can resume execution.
  • COMPLETE: All jobs have completed execution (no other jobs in the job group can run). The job group is no longer active so a new instance of the job group can be submitted.
  • Normal Job Group Flow

    Next, we will discuss the normal flow of a job group from creation to completion.

    To create a job group, a JOBGROUP JCL definition is submitted through an internal reader. The internal infrastructure of the job group is built. If a problem is found during this processing, the job group job log will show a $HASP1111 message indicating the job group contains errors. A display of the job group using the $DG command will show a status of JOB_GROUP_STATUS=ZOD_NOT_FND, meaning that a “logging job” JQE was initially allocated to track the JCL for the job group definition. However, errors were encountered, and no job group control block (ZOD) was written to the checkpoint for the job group because it didn’t complete input processing successfully.

    If the submission of the job group definition is successful, the status becomes JOB_GROUP_STATUS=PENDING. This is always the initial state of a job group directly after creation. PENDING means that the general network infrastructure exists in the checkpoint but no jobs (JQEs) have been submitted and “registered” to the network yet.

    When the first job is submitted and “registered” to the job group, the status becomes JOB_GROUP_STATUS= ACTIVE,INIT. The status will remain ACTIVE,INIT until the last job defined in the job group is submitted and registered. At that time the status becomes JOB_GROUP_STATUS=ACTIVE. During this time, any job that has all of its dependencies marked as COMPLETE can either be “flushed” or “released into execution,” depending on how those dependencies are resolved. A dependency can only become COMPLETE when its associated parent job completes execution or is flushed.

    
    EXAMPLE:  Review of how JEC jobs are released into execution or flushed. 
        Refer to Figure 1 for an example of commands that show the job group jobs 
        and their dependency status.
    
              Suppose we have this network with three parent jobs and one dependent job:
    
                JOBA JOBB  JOBC      
                    \  |  /
                     \ | /   
                     JOBD (FLUSHTYP=ALLFLUSH)
    
              Scenario 1: - Dependency JOBA->JOBD is PENDING (because JOBA is not COMPLETE yet)
                            Dependency JOBB->JOBD is COMPLETE-FLUSH
                            Dependency JOBC->JOBD is COMPLETE-SATISFY
    
                          - Conclusion: - No action is taken on JOBD until JOBA completes and the 
                                          JOBA->JOBD dependency is resolved.
    
              Scenario 2: - Dependency JOBA->JOBD is COMPLETE-FLUSH
                            Dependency JOBB->JOBD is COMPLETE-FLUSH
                            Dependency JOBC->JOBD is COMPLETE-SATISFY
    
                          - Conclusion: - JOBD is released into execution because no dependencies are
                                          PENDING and FLUSHTYP=ALLFLUSH (that is, ALL dependencies must
                                          Be COMPLETE-FLUSH for JOBD to be flushed).
    
              Scenario 3: - Dependency JOBA->JOBD is COMPLETE-FLUSH
                            Dependency JOBB->JOBD is COMPLETE-FLUSH
                            Dependency JOBC->JOBD is COMPLETE-FLUSH
    
                          - Conclusion: - JOBD is flushed because no dependencies are
                                          PENDING and FLUSHTYP=ALLFLUSH (that is, ALL dependencies are
                                          COMPLETE-FLUSH and therefore JOBD is flushed).
    

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.


comments powered by Disqus

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