|
|
|
|
|
It is possible that more than one generic decollating mission matches the same job. In this case, the missions are processed according to their priority levels. If their priorities are equal, they are processed in the order in which they appear in the Active Missions file (that is, in the order in which they were ordered or scheduled).
When GENERIC=Y and MONITOR is blank, the mission is ordered separately for each monitor and each copy of the mission is assigned a different monitor number (ID). This enables concurrent decollating of generic jobs under more than one monitor.
It is also possible that a match may occur between a generic definition and a regular report decollating mission. This duplication should not create problems, because it is impossible to specify a generic class in an ON CLASS statement of a regular report decollating mission. However, if a regular (ON DSN) report decollating mission is specified with parameter WHEN IN QUEUE=Y, it may never execute, because its job’s output is deleted by a generic decollating mission. If WHEN IN QUEUE=Y is specified for a regular report decollating mission, make sure that the job’s output is not deleted by a generic mission.
In an environment using a production control system there is a significant advantage in decollating job reports using regular report decollating missions. The decollating of the reports can be made dependent on a prerequisite condition that is added by the production control system after checking that the job has finished executing OK. Using this method, erroneous reports are not decollated. On the other hand, MSGCLASS output of the job (on another class) is best handled by a generic decollating mission.
For example, generic decollating missions can be used to
Control‑D first handles regular report decollating missions according to their priority and then scans the generic output classes for outputs. However, this does not guarantee that the regular mission of the same job is executed before a generic one.
Parent Topic |