Methods of running BMCTRIG
BMCTRIG can identify exceptions and generate jobs in a single invocation.
As an alternative method, you can split the processing into two independent phases as follows:
In the first execution, allow BMCTRIG to analyze objects and identify exceptions conditions. Make sure you specify SAVE Y on the BMCTRIG Exception Options dialog panel to write the exceptions to the Exceptions table.
Review the exceptions that were initiated and optionally modify them on the Active Exceptions List dialog panel (by choosing Object Exceptions > View logged Exceptions needing Corrective Action generation from the DASD MANAGER PLUS Main Menu). You can use this dialog to do the following tasks:
- Remove exceptions.
- Inactivate exceptions.
- Change the priority of an exception.
- Add a corrective action or modify the corrective action for an exception.
Execute BMCTRIG a second time by using the RESUME Y option. This option reads the Exceptions table and generates corrective actions for any exception where the Active indicator is set to Y.
If a corrective action is not logged in the Exceptions table, BMCTRIG uses the default action if you have specified one in the command syntax. If you have not specified a default action, BMCTRIG ignores the exception and does not generate an action for it.
To use system triggers in one area but not both, run a two-step BMCTRIG process by using RESUME Y for the second invocation. For example, specify SYSTEMTRIGGERS N for the exception identification process. Then use SYSTEMTRIGGERS Y during the RESUME processing.
Grouped services
Grouped services allow you to process multiple table spaces at one time or multiple partitions (for some utilities) when you run a utility.
Grouped services are more efficient and lead to greater performance. BMCTRIG can generate the following services as grouped services when the Execution type is G (grouped):
- AMICOPY
- AMICOPYI
- AMIMOD
- BMCREORG
- BMCSTATS
- BMCUPRS
- BMCCPRS
- FULLCOPY
- INCRCOPY
- QUIESCE
- REORG
- RESIZE
- RUNSTATS
Grouping them as follows leads to greater efficiency:
Grouped services allow you to process multiple partitions as well.
You can group them in the worklist as follows:
BMCTRIG generates grouped services only for contiguous services (that is, more than one grouped service in a sequence) that are at the beginning or end of actions as grouped services. In the following example, BMCTRIG groups the first and last services:
2. service that cannot be grouped
3. service that cannot be grouped
4. grouped service
For example, if a corrective action contains several services, and BMCTRIG is generating these services for more than one object, the table spaces appear ungrouped in the worklist, as follows:
-BMCL LOAD TABLESPACE DB.TS1 service that cannot be grouped
-BMCU BMCSTATS TABLESPACE DB.TS1 grouped service
-BMCC COPY TABLESPACE DB.TS2 grouped service
-BMCL LOAD TABLESPACE DB.TS2 service that cannot be grouped
-BMCU BMCSTATS TABLESPACE DB.TS2 grouped service
BMCTRIG processes at the action service level first and then determines groups at the object level. In this example, BMCTRIG determines that both the first and last services (AMICOPY and BMCSTATS) can be grouped for the TABLESPACE DB.TS1 objects. BMCTRIG then determines that the first and last services (AMICOPY and BMCSTATS) can be grouped for the TABLESPACE DB.TS2 objects. In this scenario, BMCTRIG generates the following worklist:
-BMCL LOAD TABLESPACE DB.TS1
-BMCL LOAD TABLESPACE DB.TS2
-BMCU BMCSTATS TABLESPACE DB.TS1 TABLESPACE DB.TS2
In the next example, BMCTRIG ignores the middle grouped service because it falls between two services that cannot be grouped. BMCTRIG groups only the first and last services, as follows:
2. UNLOAD service that cannot be grouped
3. QUIESCE grouped service [ignored]
4. LOAD service that cannot be grouped
5. COPY grouped service
If lines 2 and 4 were removed, the QUIESCE could be grouped.
Workload balancing
Workload balancing is available only when you are generating standard JCL format. You specify JCLWLB Y and a maximum number of jobs with NUMJOBS.
BMCTRIG performs work balancing by ordering the object-action occurrences by priority and then by cost. BMCTRIG determines the cost by adding the number of active pages that the service will process for each service in the action for that object. If the service is at the space level, the cost is the number of pages for the space. If the service is at the partition level, the cost is the number of pages for the partition. If the service will process indexes along with the table space or partition, it adds the pages for the table space and index partitions. The BMCSTATS tables provide the number of active pages. If no statistics exist, BMCTRIG retrieves the physical size from the ICF catalog.
Some services have no associated cost, such as ALTERSEC, AMIMOD, BR14, IDCAMS, MODIFY, QUIESCE, REPAIR, REPORT, RESIZE, START, STOP, and SYNC.
The objects are assigned to a job by assigning them to the lowest cost job. The job is the lowest cost if the sum of the object-action costs in it is the lowest of the jobs. When a job exceeds the maximum number of steps, no more work can be assigned to it. If objects cannot be assigned to any job due to exceeding the number of steps, BMCTRIG issues a warning message, and the exceptions for that object-action will remain active.
For workload balancing, the following rules for generating actions apply to BMCTRIG:
- All actions for an object are kept together in the same job.
- All partitions for an object are kept together if any action contains a service that does not support part level processing.
- Related indexes and the corresponding table space are kept together when any of the following conditions exist:
- Resizing is specified in any action
- An index will be escalated to the table space for a service
- RECOVER is in any action
- REORG or BMCREORG and the table space have at least one nonpartitioned index
Related topic
Overview of the main features of BMCTRIG