When your program issues a VSAM read or write, the access method starts an I/O operation: it builds a channel program, issues Start I/O, and the data moves between disk and memory asynchronously. Your program must not use the buffer or assume the record is available until that I/O has actually finished. So the system needs a way to block your task until the I/O completes—that is, to synchronize the task with the I/O event. On z/OS this is done with the WAIT macro and Event Control Blocks (ECBs). The task issues WAIT on an ECB; when the I/O completes, the I/O supervisor POSTs the ECB; the task is then made dispatchable again and continues. This page explains how wait and task synchronization work for VSAM I/O: WAIT, ECB, POST, synchronous versus asynchronous requests, and why this matters for correct and efficient programming.
I/O to disk is slow compared to the CPU. If the program had to sit in a tight loop checking whether the I/O was done, it would waste CPU time and could still use the buffer before the data had arrived. Instead, z/OS uses an event-driven model: the program says "I cannot continue until this I/O is done" and gives up the CPU. The system marks the task as waiting and dispatches other work. When the I/O completes, the system marks the event as complete (POSTs the ECB) and makes the task dispatchable again. When the task runs next, it continues right after the WAIT and can safely use the buffer. So the task is synchronized with the I/O completion without busy-waiting.
An Event Control Block (ECB) is a small piece of storage that represents one event. In its simplest form it is one fullword. Before the event has occurred, the ECB is in a "not posted" state (e.g. certain bits or the value indicate waiting). When the event occurs—for example, an I/O completes—the system or the I/O supervisor executes a POST macro (or equivalent) for that ECB. POSTing sets the ECB to a "posted" state. The exact format and values are defined by the operating system; the important point is that WAIT and POST use the same ECB to coordinate: one or more tasks wait on it, and when it is posted they are unblocked. VSAM (and other access methods) associate an ECB with each I/O request so that when the channel subsystem completes the I/O, the correct ECB is posted and the correct task can continue.
The WAIT macro is issued by the program (or by the VSAM code on behalf of the program) to wait for one or more events. You pass an ECBLIST—a list of ECB addresses—and optionally specify whether to wait for all of them to be posted or for a minimum number. The operating system checks the ECBs. If the condition is already satisfied (e.g. all are already posted), control returns immediately. If not, the task is placed in a wait state: it is removed from the dispatchable queue and will not receive CPU time until the ECBs have been posted. When the I/O completes, the I/O supervisor POSTs the ECB; the dispatcher then finds the task that was waiting on that ECB and makes it dispatchable. The next time that task is selected to run, it continues at the instruction after the WAIT. So from the programmer's view, the GET or PUT "returns" when the I/O is done; under the covers, WAIT and POST provide that synchronization.
| Term | Description |
|---|---|
| WAIT | Macro that blocks the task until one or more ECBs have been posted. The task is placed in wait state and is not given CPU time until the condition is satisfied. |
| ECB (Event Control Block) | A control block (typically one fullword) that represents an event. Before the event, it is "not posted"; when the event occurs, it is POSTed. Used for I/O completion and other signalling. |
| POST | The action of marking an ECB as complete. The I/O supervisor POSTs the ECB when the I/O completes. All tasks waiting on that ECB become dispatchable. |
| ECBLIST | A list of ECB addresses (and optionally flags) passed to WAIT. The task waits until the requested number of events from the list have been posted (e.g. wait for any one, or wait for all). |
In a synchronous VSAM request, the application issues a single request (e.g. GET) and the task waits until the I/O completes and the record is in the buffer; then the macro or API returns. So one request = one wait. In an asynchronous request, the application can issue multiple requests (e.g. multiple GETs) without waiting; each request starts an I/O and returns immediately. The application then issues CHECK or WAIT later to wait for one or all of the outstanding I/O operations to complete. Asynchronous I/O can improve throughput when you have multiple I/O requests in flight: the channel can be busy with several operations while the program prepares the next set of requests. VSAM supports both modes via the RPL (Request Parameter List) options. For many batch programs, synchronous I/O is simpler; for high-performance or overlap scenarios, asynchronous I/O is used. In both cases, the underlying mechanism is the same: an ECB is associated with the I/O, and when the program needs the result it waits (either implicitly in the sync case or explicitly via CHECK/WAIT in the async case) until the ECB is posted.
The WAIT macro can take a list of ECBs. You can wait for "any one of these" to be posted (e.g. first I/O to complete) or for "all of these" to be posted. The format of the ECB list (ECBLIST) and the exact syntax depend on the macro. Typically the list contains the addresses of the ECBs and possibly flags (e.g. to distinguish internal vs external ECBs). This is useful when you have multiple asynchronous I/O operations and want to wait for a specific subset or for all to complete. VSAM uses this when handling multiple concurrent requests; the application can do the same when using async RPLs and multiple buffers.
The WAIT macro has certain requirements: the task must be in a state where it can wait (e.g. dispatchable unit of work), interrupts must be enabled for I/O and external interruptions so that the I/O completion interrupt can occur and the ECB can be posted, and the ECB (and ECBLIST if used) must reside in the home address space. If you hold a lock while issuing WAIT, you might create a deadlock if the code that would POST the ECB needs that lock. So the programming guidelines are to avoid holding enqueue or other locks across a WAIT, and to ensure the ECB is in valid storage. For high-level language programs using VSAM, the language runtime and VSAM handle the WAIT/ECB details; you see the effect when a read or write call returns after the I/O has completed.
When you open a VSAM file or issue a GET or PUT, the VSAM code builds an I/O request. For each request there is an associated ECB (or the request is tied to an ECB that VSAM manages). When the request is synchronous, VSAM starts the I/O and then issues WAIT on the ECB; when the I/O completes, the I/O supervisor POSTs the ECB, the task is unblocked, and VSAM returns to your program with the result. For asynchronous requests, VSAM starts the I/O and returns to your program without waiting; when you later call CHECK or wait on the ECB list, the same WAIT/POST mechanism ensures you do not proceed until the I/O you care about has completed. So whether you use sync or async, the synchronization between "I/O in progress" and "I/O done, buffer valid" is achieved through the ECB and WAIT/POST.
You ask the teacher to get you a book (I/O request). The teacher goes to get it. Instead of standing there doing nothing, you sit down and wait (WAIT). The teacher puts a ticket on your desk (ECB). When the book is ready, the teacher marks the ticket (POST). Now you can look at the ticket, see it's marked, and use the book. The ticket is like the ECB: you wait until it's "posted" before you use the result.
1. What does WAIT do to the task?
2. Who typically POSTs the ECB after a VSAM read?
3. What is the main purpose of task synchronization for I/O?