Choosing a serialization service

The serialization service that you choose depends on factors such as the type of processing you need to perform and the scope of your application. For example, your application might require that you serialize resources: Other requirements for your serialization service might include support for SRB mode callers or cross memory capability.

Table 1 shows the resource serialization services that are available on MVS, the functions that each service can perform, and where to find more information about each service:

Table 1. Summary of Serialization Services Available on MVS
Service Function Reference
ISGENQ, ENQ/DEQ/RESERVE
  • ISGENQ: Obtain, change, and release user-defined logical resources (ENQs) and direct access storage device (DASD) Reserves.

    Serialize resources (such as data sets) within a single MVS address space, single MVS system or across multiple MVS systems.

    ISGENQ fully supports 64-bit callers.

    ENQ/DEQ: Obtain, change, and release user-defined logical resources (ENQs).

    IBM® recommends using the ISGENQ service over ENQ/DEQ/RESERVE.

    Serialize resources (such as data sets) within a single MVS address space, single MVS system or across multiple MVS systems.

    Ensure that a routine can complete its use of a resource without interruptions that could cause the routine to end (must-complete function).

    RESERVE: Allow multiple systems, need not be all MVS, to share direct access storage device (DASD).

    IBM recommends using the ISGENQ service over ENQ/DEQ/RESERVE.

    Note: Information regarding requests made to the preceding services can be gathered by ISGQUERY or GQSCAN. Also, ISGADMIN can be used to control certain aspects of the preceding services. See ISGADMIN information in z/OS MVS Programming: Authorized Assembler Services Reference EDT-IXG.
Latch Manager Callable Services: ISGLCRT, ISGLCR64, ISGLOBT, ISGLOB64, ISGLREL, ISGLRE64, ISGLPB64, ISGLPRG, ISGLPR64, ISGLID, ISGLID 64 Serialize resources (such as control blocks or data sets) within a single address space or across several address spaces in a single MVS system with minimal overhead.

Authorized programs only.

Synchronize the execution of programs.

 Global resource serialization latch manager
Locking (SETLOCK macro) Serialize system resources (such as MVS system queues or control blocks) within a single MVS system or address space. Locking
IXLLOCK Enables authorized applications to obtain shared or exclusive serialization on user-defined logical resources. You can also implement your own locking protocols through the inclusion of user data.

IXLLOCK is specific to Sysplex environments and provides high speed cross sysplex sharing. The cost is that it is much harder to use then ENQ and provides less external controls

For guidance information, see z/OS MVS Programming: Sysplex Services Guide.

For the programming environment, see z/OS MVS Programming: Sysplex Services Reference.

If you need to synchronize the execution of programs, Table 2 can help you determine which services to choose. The table compares the attributes of the Pause, Transfer, and Release callable services, the WAIT and POST macros, and the SUSPEND and RESUME macros.

Table 2. Program Serialization Techniques Description
Pause, Release, and Transfer WAIT and POST SUSPEND and RESUME
Can change the dispatchability of a task or SRB. Can change the dispatchability of a task but not an SRB. Can change the dispatchability of a task or SRB.
Can be called from TCB mode or SRB mode. The interfaces are the same for both modes, and the caller of the services does not need to know whether it is in TCB or SRB mode. WAIT can only be issued in TCB mode. POST can be issued in TCB or SRB mode. The interfaces used in each mode may be different. Can be used in both TCB and SRB mode. The invoking program must know if it is in task or SRB mode.
Can release a task or SRB before it is paused Can post a task before it waits. Cannot resume either a task or SRB before it is suspended.
An authorized caller can pause and release any task or SRB in the system. Requires the ECB and task being posted to be in the current primary address space for a non-cross memory post. No control element is needed.
A task or SRB can only pause on a single Pause Element (PE) at a time. A task may wait on multiple ECBs. If the wait count numbers are posted, the task is made ready. Not applicable.
The Transfer service can simultaneously pause one task or SRB and release another. There is no single service with comparable capability for WAIT and POST. There is no single service with comparable capability for SUSPEND and RESUME.
The Transfer service can release a task or SRB and immediately pass control to the released task or SRB. There is no single with comparable capability for WAIT and POST. There is not single service with comparable capability for SUSPEND and RESUME.
Both authorized and unauthorized callers can use the services. Both authorized and unauthorized callers can use the macros. Only authorized callers can use the macros.
The system ensures that pause elements are not reused improperly, thus avoiding improper releases caused by unexpected termination or asynchronous ABENDs. Callers can incorrectly post a task out of the wrong wait due to post, or even the wrong task, if managed improperly, through task termination. Callers can resume the wrong task or resume a task from the wrong suspend. Because no control element serializes SUSPENDs and RESUMEs, neither the system nor the user can easily detect any reuse problems.
Local lock is not used by the services; therefore, its usage has no negative effect on local lock contention. Services using local lock can cause additional contention. Services may use local lock, and cause some additional contention.
Control the parallel execution of units of work (task or SRB) within the same MVS address space or across MVS address spaces. Allow programs to wait (pause) until one event (RELEASE or TRANSFER) has completed. Control the parallel execution of tasks. Allow programs to wait until one or more events have completed (event completion function). Control the parallel execution of request blocks (RBs) and SRBs within a single MVS system or address space.

If you need to serialize resources across multiple MVS systems, you must use the ISGENQ macro or the ENQ/DEQ/RESERVE macro. However, if your application requires resources that reside in a single address space or MVS system, you can choose one of the following services: the CMS lock, ISGENQ, ENQ/DEQ macros, latch manager, the local lock, or IXLLOCK. Table 3 can help you determine which of the serialization services is most appropriate for your application.

Table 3. Comparison of CMS Lock, Local Lock, Latch Manager, and ISGENQ and ENQ/DEQ Serialization Services
Feature CMS Lock Local Lock Latch Manager ENQ/DEQ Macros ISGENQ Macro
Number of items you can serialize individually One One Many Many Many
Access allowed Exclusive Exclusive Exclusive and shared Exclusive and shared Exclusive and shared
Scope Single system Address space Single system or address space Address space, single system, or multiple systems Address space, single system, or multiple systems
Cross memory environment Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN Any PASN, any HASN, any SASN.
Unit of work Task or SRB routine Task or SRB routine Task or SRB routine Task Task
Minimum authorization Supervisor state and PSW key 0 Supervisor state and PSW key 0 Supervisor state or PSW key 0-7 Problem state with any PSW key, supervisor state or PSW key 0-7 or APF-authorized for certain types of requests Problem state with any PSW key, supervisor state or PSW key 0-7 or APF-authorized for certain types of requests
Set-up required None None Application must create one or more latch sets None None
Default recovery action Release owned and pending requests Release owned and pending requests Release pending requests, but not owned requests Release owned and pending requests Release owned and pending requests

Other techniques, such as those that make use of the compare and swap (CS), compare double and swap (CDS), and test and set (TS) instructions, are provided to perform specialized serialization. For information about those instructions, see Principles of Operation.

The capabilities listed in Table 3 are explained below:

Number of items you can serialize individually
The latch manager and ISGENQ allow your application more control over the way it divides resources into individual units and assigns serialization to those resources. This increased control allows you to reduce contention for resources and improve the overall performance of the application. For example, an application can use several latches to serialize resources within an address space, instead of using the address space local lock (of which there is only one) to serialize those resources.
Access allowed
Granting shared access minimizes resource contention because several requestors can read a resource at the same time. The CMS and local locks do not provide shared access to resources. Each unit of work that requests the CMS or the local lock must obtain exclusive access, even though shared access might be enough. The latch manager and the ISGENQ macro allow programs to request shared or exclusive access to resources.
Scope
The CMS lock and the latch manager can be used to serialize resources only within a single MVS system. The local lock is restricted to a single address space. The ISGENQ macro can be used to serialize resources across multiple MVS systems (as well as a single MVS system).
Cross memory environment
With a cross memory environment established, your application can use the CMS lock, latch manager, or local lock to serialize resources across address spaces within a single MVS system. When the latch manager is being used in a cross memory environment, the current latch set must reside in the primary address space.
Unit of work
The CMS lock, local lock, and latch manager are available to programs that run in task or SRB mode. The ISGENQ macro is available only to programs that run in task mode (SRB routines cannot issue ENQ/DEQ).
Minimum authorization
Programs must run in supervisor state and PSW key 0 to obtain the CMS or local lock, and supervisor state or PKM 0-7 to obtain a latch. The ISGENQ macro is available to programs running in problem state with any PSW key. Supervisor state, PSW key 0-7, or APF authorization is required for certain types of ISGENQ requests.
Set-up required
The CMS lock, local lock, and the ISGENQ macro do not require applications to perform any set-up; the system creates the required structures. Before your application can use the latch manager to serialize resources, the application must create one or more latch sets.
Default recovery action
For the local and CMS locks, the system releases owned and pending serialization requests when the last functional recovery routine (FRR) percolates. For the ISGENQ macro the system releases owned or pending serialization requests during task or address space termination. (See "Releasing the Resource" in z/OS MVS Programming: Assembler Services Guide for more discussion about what happens when a task associated with an ENQ terminates before the ENQ is released.)

For performance reasons, and because SRBs might not want to release owned latches when errors occur, the system does not release owned latch requests during task or address space termination. The system does, however, release pending latch requests when the requestor's home address space terminates.

In all cases, the application programmer needs to understand the default recovery action for the service that is used. For more information on how to create a recovery environment, see the information that discusses recovery and termination.

Parent topic: Serialization