A Model Work Flow

Figure 22 shows how a multisystem work scheduler can use the IWMSEVAL and IWMSEDES services to implement support of scheduling environments.

Figure 22. Scheduling Environment Flow

In Figure 22, work request ZJOB9 is submitted and associated with the DB2LATE scheduling environment.

The scheduler calls the IWMSEVAL service to verify that the scheduling environment name is valid. If there is no such scheduling environment known to workload management, then the scheduler fails the work request. If the scheduling environment name is valid, then the scheduler accepts the work request.

The scheduler creates a queue element for the work request. The scheduling environment name is included in that queue element, as well as a resource affinity mask. For each system in the sysplex, IWMSEDES will indicate whether that system satisfies the scheduling environment in question. The scheduler can then build the resource affinity mask, which is simply a 32-bit string of ones and zeros. A one means that the system satisfies the scheduling environment, and a zero means that the system does not satisfy the scheduling environment. The scheduler must keep an ordered list of system names corresponding to the bit positions in the mask.

In Figure 22, the resource affinity mask for DB2LATE reads “0100”, because only SYS2 satisfies the DB2LATE scheduling environment.

Scheduling environment definitions and resource state settings can change at any moment. The scheduler must be aware of these changes so that it can adjust its decision-making accordingly. The scheduler listens for two ENF events, 41 and 57, which signal these changes:

41

A new service definition has been activated. When a new service definition is activated, resource names can be added to, or removed from, a scheduling environment. A particular scheduling environment or resource name may even have been deleted from the service definition altogether. (See note below.)

57

A scheduling environment has changed state on a system. It was not available and now is, or vice versa.

For more information about ENF, see z/OS MVS Programming: Authorized Assembler Services Guide.

For either event, the scheduler must reevaluate the status of each work request on the queue. It must rebuild the resource affinity masks to reflect the new scheduling environment definitions or the new resource state settings.

If a scheduling environment no longer exists, the scheduler can either delete the associated work requests or place them in a hold state for installation action. The latter choice is appropriate if it is important for the installation to be able to recover the work requests. The installation could recover by installing a new service definition that includes the deleted scheduling environment.

The final step in this work flow is when the work request moves from the queue to the appropriate system for execution. In Figure 22, the ZJOB9 work request is scheduled on SYS2, as that is the only system that satisfies the DB2LATE scheduling environment.