What is the effect of the MAINT field on the CA 7 Job Definition Panel (DB.1)?
Article ID: 189817
Updated On:
Products
Issue/Introduction
Dataset based trigger jobs are not triggering when MAINT=Y. However, dataset requirements were added to jobs when changed MAINT from Y to N. How will changing MAINT from Y to N impact jobs requirements? Is there some other change to suppress that, or is that how it is when MAINT is change to N?
Environment
WA CA 7 Edition
Resolution
The MAINT field has two options (Y or N). If MAINT=Y, all input data set requirements are ignored. None of the output data sets created by the job is posted back to Workload Automation CA 7 Edition product. The job is at that point considered to be a maintenance type job. Marking a job as MAINT allows job triggering but no data set triggering can occur. If the LOADDSNS keyword is used on the DBASE statement in the initialization file, the LOAD process does not build any DD or data set information for jobs that are marked MAINT=Y on the DB.1 (JOB) panel. This means that there are not any data set connections for these jobs unless added manually.
Scenario 1:
If the DB.1 CPU Job Definition screen has MAINT: N and the DB.6 Data Set Definition screen has TYPE: NORM, the data set will be added as a requirement for that job in the queue.
Scenario 2:
If the DB.1 CPU Job Definition screen has MAINT: Y and the DB.6 Data Set Definition screen has TYPE: NORM, the data set is always a satisfied requirement for this job in the queue.
Scenario 3:
If the DB.1 CPU Job Definition screen has MAINT: N and the DB.6 Data Set Definition screen has TYPE: PERM , the data set will NOT be added as a requirement for that job in the queue.
Scenario 4:
If the DB.1 CPU Job Definition screen has MAINT: Y and the DB.6 Data Set Definition screen has TYPE: PERM , the data set will NOT be added as a requirement for that job in the queue.
Additional Information:
If you would like to override Scenario 1 and have a particular data set NOT be a requirement for the job, you could update the DB.3.1 Data Set Predecessors screen with PERM : Y.
If the DB.6 Data Set Definition screen has TYPE: PERM , a data set will never be an unsatisfied requirement for any job.
There are several methods of adding data sets to the database. The primary method is accomplished through the LOAD process. When a job is loaded, all data set names referenced in the JCL are added to the database if those names are not already in the database. If the LOADDSNS keyword is used on the DBASE statement in the initialization file, then the LOAD process does not build any DD or data set information for jobs that are marked MAINT=Y on the DB.1 (JOB) panel. Data sets can also be added to the database by using the DB.6 panel ADD function.
If data set information already exists in machine-readable form, a program can be written to perform the DB.6 panel functions with batch commands and the Batch Terminal Interface (BTI) facility.
External Data Set Tracking/Triggering is a CA 7 feature that allows you to track data sets not created under CA 7 control. Tracking these data sets gives you the opportunity to perform external data set posting or job triggering. In order to have an external data set be used for posting for triggering you must first define the data set to the CA 7 database. Once this definition has occurred and the table properly loaded, CA 7 will then monitor the system for SMF 15 records containing your data set.
This document is intended to be a quick reference for setting up this process. For job triggering to occur for these data sets,
you perform the following steps. Each step is further described below.
STEP 1. Define the dataset to the SASSSXDSN table.
STEP 2. Define the job to CA 7 (DB.1 Job Definition screen entry).
STEP 3. Define the data set to CA 7 as NORM (DB.6 Data Set Definition screen entry).
STEP 4. Set up the data set trigger (DB.2.6 Data Set Triggering screen entry).
STEP 5. Refresh LLA.
STEP 6. Reinitialize CAS9 to load SASSXDSN.
The External Data Set Tracking Criteria Table is comprised of one or more $L2XDSN macro calls. After the module is coded, it must be assembled and linked. The module must be accessible to the CAIRIM procedure and identified using the XDSN parameter in the CA 7 System Configuration File.
Feedback
