CA Jobtrac Job Management r11: things to consider for generic resources or mutually exclusive processing.

Products

• Jobtrac

Issue/Introduction

This Knowledge Document describes what to take into consideration when managing CA Jobtrac JM controlled jobs using generic resources or mutually exclusive processing for events.

 

Environment

Release:
Component: JOBTRC

Resolution

Consider the following when managing generic resources or in defining mutually exclusive events:

1. Resource checking for generic resources is done at job SUBMISSION time. This means, if a job is in the JES Input queue (waiting to execute/has not started) for a long time that has a generic resource defined for it, then the job's corresponding resource is also blocked for the same length of time.
   
   
2. The "in-use" counts of generic resources are ONLY maintained in an in-core table. This is done by the CA Jobtrac/Primary system, since only the Primary
   deals with job submission. The consequence of this is, if you invoke the @RES as a top line command under the ISPF interface and if this TSO user is running on the same LPAR as a CA Jobtrac/Monitor system, then you'll always see ZERO (0)for these "in-use" counts as Monitors don't deal with job submission.
   
   
3. Generic resources can also be connected to DUMMY events, but DUMMY jobs will NEVER be considered as submitted. That is, the "in-use" count of a generic resource won't be incremented in this case.
   
   
4. CA Jobtrac does "mutually exclusive" checking BEFORE submission. This "checking before submission" is done to make things easier for JES. That is, we don't want production jobs to occupy JES spool space and resources very long before the job is expected to execute. The idea being that a job submitted from CA Jobtrac should be able to begin execution right after submission.