Shared Spool Configuration with ENQ-Handling Product

The following figure shows a Shared-Spool Configuration with an ENQ-Handling Product:

Figure 35 Shared-Spool Configuration with an ENQ-Handling Product

The term "Shared-Spool" refers to "JES2 Multi-Access Spool (MAS)" or "JES3 Complex" connections between two or more MVS systems.

A Shared-Spool configuration consists of two or more JES systems sharing JES input, job, and output queues. The Shared-Spool must reside on one or more disk volumes that are shared by (connected to) all relevant mainframes.

The above diagram shows a basic Shared-Spool configuration consisting of two mainframes.

The following discussion also applies to Shared-Spool configurations with more than two mainframes.

A single Control‑M monitor is sufficient for handling the entire Shared-Spool complex. The monitor submits all jobs to CPU A but the jobs run under the appropriate CPU (CPU A or CPU B).

A job can be designated to run on a specific CPU based on the value of parameter CLASS in the JOB statement. If a job submitted by the Control‑M monitor specifies a CLASS that is only served by CPU B, JES automatically designates the job to run on CPU B.

A job can also be designated a job to run on a specific CPU through an appropriate JES statement, such as the following:

If a job submitted by the Control‑M monitor requests (through such a statement) to run on CPU B, JES automatically sends the job to CPU B.

CLASS and SYSAFF/SYSTEM specifications can be hard-coded in the job’s JCL, or can be determined dynamically and set by the Control‑M monitor during job submission.

For information on dynamically setting up CLASS and SYSAFF/SYSTEM specifications using the AutoEdit facility, see the examples of controlling the target computer by class and system affinity in the JCL and AutoEdit facility chapter of the Control‑M for z/OS User Guide.

Control‑M supports dynamic CPU workload balancing. This type of balancing is achieved through the use of quantitative resources and the Automatic Tape Adjustment facility. For more information, see the description of the RESOURCE Runtime scheduling parameter in the job production parameters chapter of the Control‑M for z/OS User Guide.

Assuming that the IOA and Control‑M software, Core, and Repository reside on a disk that is shared by the two CPUs, the Online facility can be invoked under both CPUs. For the same reason, the various IOA and Control‑M utilities and reports can be operated on both CPUs.

Special steps must be taken in order to simultaneously update a file from two CPUs. Before Control‑M updates the Repository, it issues a special ENQ with a scope of SYSTEMS. An ENQ-handling product (such as GRS or MIM) must be employed in order to pass the ENQs to all CPUs and synchronize the updates. If no ENQ- handling product is employed, data integrity is jeopardized.

Ensure that the ENQ-handling product actually handles the Control‑M ENQs. The easiest way to verify this is to enter Screen 3 of the Control‑M Online facility under CPU B, and look at the upper right corner. If the Control‑M monitor is up under CPU A, the status "UP" is displayed.

The Control‑M Event Manager (CMEM) can acknowledge the arrival or ending, of jobs or started tasks, accesses to dataset, and changes to dataset disposition (allocation, deletion, cataloging and uncataloging) performed by jobs or started tasks. If you want to receive these acknowledgments on both CPU A and CPU B, the CMEM component must operate on both CPUs.

Additional Control‑M options provide special support for the Shared-Spool environment

• SHOUT (notification) messages can be issued to users on any CPU. For further information about parameter SHOUT, see the job production parameters chapter of the Control‑M for z/OS User Guide.
• A started task (STC) can be scheduled on any CPU. For further information about parameter MEMLIB, see the job production parameters chapter in the Control‑M for z/OS User Guide.
• Operator commands can be issued in any CPU. For further information about the IOAOPR utility, see the INCONTROL for z/OS Utilities Guide.

Assuming that the Control‑M monitor runs on CPU A and a command is to be issued to CPU B, any of the following methods can be used:

• The monitor can schedule a job or started task to run on CPU B and invoke procedure IOAOPR to issue the command.
• The monitor can schedule the IOAOPR STC (or job) to run on CPU A and issue the command in such a way that it is passed to CPU B (Under JES2, use the $M command. Under JES3, use the *T command.)
• Sample Exit IOAX034A in the IOA SAMPEXIT library enables the user to issue operator commands by running a dummy job without scheduling a job or a started task using SHOUT requests.

This sample exit is suitable for all JES2 and JES3 versions (assuming that the Control‑M Monitor runs under the global JES3 processor).

You should use the first method for the following reasons:

• The command always reaches CPU B.
• Control‑M analyzes the SYSOUT of the scheduled job or started task.
• Checks whether the job or started task ran successfully or not.
• This method provides advantages from a security point of view.

Control‑M job statistics are maintained separately for each CPU These job statistics are used as input for the Control‑M Simulation and Forecasting facility. These statistics can be viewed in Screen 3.S.

From a technical point of view, the Control‑M monitor can run under any CPU. For performance considerations, see Tuning Recommendations.