Resource control

When your program executes, other programs are executing concurrently in the MVS™ multiprogramming environment. Each group of programs, including yours, is a competitor for resources available at execution time. A resource is anything that a program needs as it executes — such as processor time, a data set, another program, a table, or a hardware device, etc. The competitor for resources is actually the task that represents the program.

If you subdivide a program into separate logical parts, and code it as several small programs instead of one large program, you can make the parts execute as separate tasks and with greater efficiency. However, you must ensure that each part executes in correct order relative to the others:

The WAIT, POST, and EVENTS macros introduce a strategic delay in the running of a program. This delay forces a program to wait using an event control block (ECB), for a particular event to occur. When the event occurs, the program can run once again. The event can be the availability of a necessary resource.
Pause, Release, and Transfer are services you can call, using a pause element (PE), to synchronize task processing with minimal overhead. Table 1 compares the use of the Pause, Release, and Transfer services with the WAIT and POST macros.
The ISGENQ macro allows your program to serialize resources by:
- Obtaining a single ENQ or multiple ENQs with or without associated device reserves.
- Changing the control from shared to exclusive on one or more resources.
- Releasing a single ENQs, or multiple ENQs.
- Testing the availability of one or more resources.
- Testing how the resource request would be altered by RNL processsing or dynamic global resource serialization exits.
Note: As of z/OS® Release 6, the ENQ, DEQ, and RESERVE interfaces will continue to be supported, though IBM® recommends using the ISGENQ service for unauthorized serialization requests.
The ISGQUERY macro allows you to obtain information about the use of resources.

Table 1. Task Synchronization Techniques
Pause, Release, and Transfer	WAIT and POST
Can change the dispatchability of a task.	Can change the dispatchability of a task.
Can release a task before it is paused.	Can post a task before it waits.
An unauthorized caller can pause and release any task in the caller's home address space.	An unauthorized caller can WAIT and POST any task in the caller's home address space.
A task can only pause on a single PE at a time.	A task may wait on multiple ECBs. If the wait count numbers are posted, the task is made dispatchable.
The Transfer service can simultaneously pause one task and release another.	There is no single service with comparable capability for WAIT and POST.
The Transfer service can release a task and immediately pass control to the released task.	There is no single service with comparable capability for WAIT and POST.
The system ensures the Pause Elements are not reused improperly, thus avoiding improper releases caused by unexpected termination or asynchronous ABENDs.
Ability to pass control directly from one task to another paused task.
High performance. No local lock contentions effects.	Lower performance, possible local lock contention.
	Callers may use ECBLIST or EVENTS service to wait on multiple ECBs.