Managing split or inconsistent occurrences

In HCL Workload Automation for Z, an occurrence must always be consistent. This means that you must ensure that every operation is connected directly or indirectly.

To remove internal successors, the application must be designed in such a way that the removal of the dependencies does not create an inconsistent application. By default, if the result of removing internal dependencies would result in some operations becoming entirely separate from the rest of the occurrence then the command will fail. When you useDROPPRED or DROPSUCC, ensure that the application is designed specifically to manage such eventualities, in preference to OPTIONS DROP.

The OPTIONS DROP keyword provides 2 mechanisms that prevents occurrence inconsistencies:

  • Making both sides of the broken dependencies a successor to a named operation number, providing that the named operation number has the status Complete.
  • Adding an operation using a named workstation and job name, or reuse a matching pre-existing one that has no successors, and make this a success to both sides of the broken dependency.
The syntax of the OPTIONS DROP keyword is DROP(<predop>,<succws>,<succjob>,<succtext>), where:
<predop>
A named operation number, for example 001, to be used as a predecessor to both sides of a dropped dependency, but only if <predop> is in Complete status. It does not add <predop>, if it does not already exist.
<succws>
Name of the workstation that is used to become a successor to both sides of the dropped dependency. This must be a non-reporting general workstation.
<succjob>
Name of the job that is used to become a successor to both sides of the dropped dependency. The default is ZRELINK.
<succtext>
Operation description that is used if a successor operation is inserted. The default is Relink dropped deps.
Example of two automatic relinking scenarios shows the following scenarios:
Scenario 1
When the dependency between operations 010 and 015 is dropped, the <predop> operation 001 that was set by OPTIONS DROP is in status C. This allows it to be connected as a predecessor to operations 010 and 015, preventing an occurrence split.
Scenario 2
When the dependency between operations 010 and 015 is dropped, the <predop> operation 001 that was set with OPTIONS DROP is in status W. This prevents the relink processing to occur, therefore the operation 254 is added using the <succws> and <succjob> keywords of OPTIONS DROP. This makes operation 254 a successor to operations 010 and 015, preventing in this way an occurrence split.
Figure 1. Example of two automatic relinking scenarios


The image shows graphically the scenario 1 and scenario 2, which are described in the text.

When a dependencies is being dropped by this command, the following processing takes place in this order:

  1. If the dropping of the dependency does not cause an occurrence split, no additional dependencies are added.
  2. If <predop> is specified in OPTIONS DROP and the identified operation is in status Complete, both sides of the dropped dependency become successors to <predop>.
  3. If <predop> is not specified or it has a status different from Complete, if <succws> is specified it will look for an operation on the <succws> workstation with the <succjob> job name with no successors. If a match is found, this operation becomes a successor to both sides of the dropped dependency.
  4. If <succws> is specified, but no match is found within the occurrence, the highest unused operation number is identified and added to the occurrence to become a successor to both sides of the dropped dependency. If there are no unused operation numbers, an operation is not added.
  5. If none of the preceding processes are specified or criteria are not met, the command fails to drop the dependencies due to the occurrence split.
Note:
  1. If there is already a dependency in place to a valid <predop> or <succws> operation, the dependency is not dropped, even if identified by the ALTER command as being a dependency to drop.
  2. Specifying OPTIONS DROP causes batch to carry on processing from the point of the dropped dependency, in contradiction to the original design of the application. If OPTIONS DROP is coded in a default OPTIONS member, this could be unknown to some of your user base, and result in unexpected behavior. OPTIONS DROP must be set only in the jobs where it is to be applied.