Step 12: Set Up for Multiple CPUs

Starting Your Product › How to Configure Without CA MSM › Step 12: Set Up for Multiple CPUs

Step 12: Set Up for Multiple CPUs

All users must perform this step.

Upgrade Considerations

If you are upgrading, see the chapter "Upgrading from a Prior Release" for information that applies to this step.

Define ENQs to the System Integrity Product

The product issues ENQs and RESERVEs as necessary to maintain the integrity of its data sets. CA Deliver uses the primary ENQ (QNAME=RMOSTC) during startup and shutdown to serialize control block updates.

This enqueue is defined as SYSTEM to prevent a second CA Deliver from starting on this LPAR with the same characteristics. This ENQ does not have to be defined to a system integrity product.
A second ENQ (QNAME=RMOCKPT) is used during the OPEN and CLOSE of the checkpoint file. This ENQ does not need to be defined to a system integrity product.
The RESERVE issued by CA Deliver is normally short-lived but will cause deadlock conditions unless it is properly defined. The RESERVEs should be converted to global enqueues; however, if your environment dictates, the reserves do not have to be converted.

If the CA Deliver database and the checkpoint file are on dedicated volumes with no other datasets, you do not have to convert RESERVES to global enqueues.

Using RESERVE and ENQ

This table shows how CA Deliver uses ENQ and RESERVE.

QNAME	Type	Description	Integrity Product Control
RMOSTC	ENQ	Serializes control block updates during startup and shutdown	NO
RMOCKPT	ENQ	Serializes the CA Deliver checkpoint during open and close	NO
RMOUPD	RESERVE	Serializes the updating of the CA Deliver database	YES/NO (if environment dictates)

Database Extent Considerations

In a multiple CPU environment, it is possible that processes in each system image are accessing a database extent. To minimize contention, we recommend:

Place each database extent on a dedicated volume.
Where it is possible, match the size of the volume and the size of the database extent.
This matching allows each extent to be accessed by its own server (device address). I/Os for multiple extents are prevented from queuing on the same device address, which can happen if multiple database extents are allocated on the same device.