Every site has z/OS batch jobs that must be tracked like a production job but are submitted by something other than the job management product. For example, a payroll job stream in CA Scheduler JM may need to wait on a job that is submitted by a CICS transaction when the HR department has finished entering overtime hours.
CA Scheduler JM has always had the ability to track jobs submitted outside of CA Scheduler JM by using the $MVS table. The $MVS table has a list of job names that should be tracked. When CA Scheduler sees a JOBINIT for one of these jobs it then tracks the job as if it had been submitted by CA Scheduler JM.
The $MVS table has some limitations:
- The table must be assembled by a site's system programmer when changes are made
- CA Scheduler JM must be restarted when changes are made to the $MVS table
- CA Scheduler JM is unable to differentiate between jobs with the same name
Consider the last bullet and the example above. Suppose CA Scheduler has a payroll job stream waiting for job PAYDONE to be submitted by the HR department's CICS transaction. The problem is that any job called PAYDONE will satisfy CA Scheduler's requirement. For example, a TSO user could submit a job called PAYDONE, causing the payroll job stream to begin.
With the use CA Scheduler JM "filters," which are a new method of tracking jobs submitted from outside CA Scheduler. Filters have none of the limitations of the $MVS table. Filters are a newer tool that may be used in addition to or instead of the $MVS table.)
Filters are defined to the CA Scheduler JM database and provide rules for which jobs should be tracked.
To define a filter, log on to CA Scheduler JM and select option 2:
Then select option D:
Enter 4 to define a filter plus the name of the new filter:
The filter definition screen is displayed:
In the Masks section, provide as much detail information about the job (or jobs) that you want to track. For example, if you know that the job will be called PAYDONE, have an accounting field of 12345, and execute with userid CICSPRD, then you might fill in the screen like this:
By specifying more than just the job name you help guarantee that the job CA Scheduler JM tracks will be the job you want tracked.
In the Failure section you may specify a condition code test to determine if the job succeeds are not. If the only valid return code is zero, then you might enter:
The job will be marked "Failed" if it ends with a return code that is greater than or equal to (GE) one.
Enter END (PF3) to save the filter definition.
CA Scheduler JM will automatically start using this filter definition at the next autoscan. If you want the filter to be used prior to the next autoscan, then you must use the REFRESH FILTER command (option 6).
When CA Scheduler JM sees a job start (JOBINIT) that matches the filter definition, it adds the job to the active workload in a schedule called $MVSxxxx where xxxx is the system id (SMF ID) on which the job executed.
(Jobs tracked due to a filter look the same as jobs tracked by the old $MVS table.)
Jobs and schedules defined to CA Scheduler JM can wait on external jobs by using the MVS criteria keyword:
In this example, job PAY07 in schedule PAYROLL will not start until external job PAYDONE has completed successfully.
Note that you can change from using $MVS to filters and gain more security without having to change your existing criteria.
Using filters is an easy and secure way of tracking jobs that were submitted outside of CA Scheduler JM. Filters are easier to use than the $MVS table because changes can be made without having to reassemble a table (or involve a systems programmer) and without having to restart CA Scheduler JM. Filters are more secure than the $MVS table because you can be more specific of which jobs should be tracked-not just all jobs with a specific name.