Choosing a serialization service
- Within a single address space
- Across several address spaces within a single z/OS® system
- Across multiple z/OS systems.
Table 1 shows the resource serialization services that are available, the functions that each service can perform, and where to find more information about each service.
Service | Function | Reference |
---|---|---|
ISGENQ, 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 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 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.
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. |
![]() ![]() |
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 address space or across 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 system or address space. |
If you need to serialize resources across multiple z/OS 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 z/OS 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.
Capability | 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 |
Setup 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 following list explains the capabilities listed in Table 3:
- 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 z/OS system. The local lock is restricted to a single address space. The ISGENQ macro can be used to serialize resources across multiple z/OS systems (as well as a single z/OS 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 z/OS 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.
- Setup 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.