From the CA-7 Database Maintenance Guide
Schedule triggers can be used as a more efficient alternative to date/time schedules. Triggers cause jobs to be dynamically scheduled based solely on completion of an event. The triggering event may be date/time scheduled or it too can be automatically triggered by even another event. Schedule triggers have no association with a calendar. Therefore, no calendar related maintenance is ever required. Once defined, triggers are perpetual, remaining in effect until they are either deleted or modified by the user. In addition to relieving the user of annual calendar schedule maintenance, triggers are a far more efficient scheduling mechanism in terms of system overhead. Three types of triggers are available in CA-7:
With each trigger, you may trigger multiple jobs if you want.
Job Triggers: When a predecessor job completes successfully, a trigger initiates scheduling of the successor or dependent jobs that will be brought into the request queue. This newly triggered job may also have a trigger definition that, upon successful completion, causes another job to start. For ease of definition and understanding, the predecessor/successor relationship is commonly used to control sequencing of jobs in the production environment. Job triggers are defined with the DB.2.4 function.
Network Triggers: Input (or preprocessing) workstation networks can be used to trigger CPU jobs which are dependent on the completion of that network. These triggers take effect whenever the last workstation in the network is posted as being complete. The jobs to be triggered are defined through the DB.2.5 function.
Multiple jobs can be triggered by the completion of a single network. Output (or postprocessing) networks cannot be used to trigger jobs.
Data Set Triggers: Data set output activity can also be used as a trigger. Whenever a sequential data set is created or updated, CPU jobs can be triggered by the completion of that activity. Scheduling of jobs in this manner is accomplished through the DB.2.6 and DB.6 panels.
A data set cannot be used as a trigger if it is defined as PERM=YES on the DB.6 panel or if it is output by a job which is defined as MAINT=YES.
Data set triggers are very useful if you have a job which needs to run only if a specific data set has been created.
If the data set used as a trigger specifies YES for the DB.6 panel parameter POST AT CLOSE TIME, the data set trigger takes effect when the data set is successfully closed after being opened for output or update. If POST AT CLOSE TIME is NO, then the trigger takes effect on successful completion of the job in which the data set was created or updated.
The advantage of posting at close time is that successful completion of an entire job is not necessary for data set triggering or requirement posting to take place.
Note: If you trigger a job at data set close, the trigger occurs then, even if the job that created the data set later abends. If the abended job is then restarted and the data set is recreated, the trigger occurs again.
So the real question becomes -- why are you not able to read the manual?