When your application opens a VSAM file, reads a record, or writes data, the request eventually reaches code that must perform real I/O: moving data between disk and memory, updating control blocks, and coordinating with the z/OS I/O subsystem. That code cannot run in "problem state" (the normal mode for user programs). Instead, the system uses a Supervisor Call (SVC)—a hardware instruction—to switch the CPU into "supervisor state" and branch to the routine that does the work. So the SVC is the bridge between your VSAM call and the I/O driver. This page explains what an SVC is, how z/OS uses it for VSAM I/O, the SVC types and numbering, and why it matters for understanding how VSAM performs I/O on the mainframe.
On IBM mainframes (and compatible systems), the CPU can run in different states. In problem state, the program can access only its own memory and cannot execute certain privileged instructions (such as Start I/O or modify system control blocks). In supervisor state, the program can execute those instructions and access system areas. An SVC is a single machine instruction (operation code 0A in hexadecimal) that the program uses to request an operating-system service. The instruction includes a number from 0 to 255—the SVC number. When the CPU executes the SVC, it switches to supervisor state and uses that number to look up an entry in the SVC table; the table entry points to the routine that handles that SVC. Control is transferred to that routine, which runs in supervisor state, does the work (e.g. I/O), and then returns control to the caller. So from the application's point of view, you call VSAM; VSAM (or the language runtime) builds a parameter list and issues an SVC; the SVC routine performs the actual I/O or access-method logic; when it finishes, your program continues.
VSAM is implemented as part of the z/OS access method layer. When you use high-level interfaces (such as the ACB/RPL macros in assembler, or equivalent C/C++ or COBOL APIs), your program calls code that prepares a request. That code might build or update an RPL (Request Parameter List), set up buffers, and then issue an SVC. The SVC number used is one that has been assigned to the VSAM or I/O component. The routine that runs in response to that SVC has access to supervisor state and can, for example, issue a Start Subsystem (SSCH) or Start I/O (SIO) to the channel subsystem, wait for the I/O to complete, update the VSAM control blocks, and return the result (e.g. record data or condition code) to your program. So the SVC is the mechanism that allows the "user side" of VSAM to hand off to the "driver side" that actually talks to the hardware and performs the transfer of control intervals between disk and memory.
z/OS maintains a table of SVC routines. Each entry corresponds to one SVC number. The table is built at IPL (Initial Program Load) from definitions in PARMLIB—typically the IEASVCxx member. IBM reserves SVC numbers below 200 for system use; numbers 200–255 are often used for user-written or vendor SVCs. So when you hear "SVC 32" or "SVC 64", that refers to the SVC instruction with that number and the routine in the table at that index. VSAM and related components (e.g. OPEN, CLOSE, GET, PUT) use specific SVC numbers that are documented or implied by the control block formats. As an application programmer you usually do not need to know the exact number; you use the macros or APIs, and the correct SVC is issued for you.
SVCs are classified by type. The type determines where the routine is loaded from and whether it resides in the nucleus (the core of the operating system) or in the Link Pack Area (LPA), which is shared, reusable code. Type 1, 2, and 6 SVCs are linked into the nucleus; they are always in memory and are used for critical functions. Type 3 and 4 SVCs are loaded from LPA; they are also in memory but come from library modules. Type 5 is used for dummy or placeholder entries. This matters for performance and maintenance: nucleus SVCs are fixed in the system; LPA SVCs can be updated by replacing the LPA module. VSAM and other access methods typically use type 3 or 4 SVCs so that they can be updated without rebuilding the nucleus.
| Type | Location | Description |
|---|---|---|
| Type 1, 2, 6 | Nucleus (IEANUC0x) | Routines linked into the z/OS nucleus; always in memory. Used for critical system functions. |
| Type 3, 4 | LPA (Link Pack Area) | Routines loaded from LPA libraries; shared across address spaces. Often used for access methods and common services. |
| Type 5 | Dummy | Placeholder entry; no real routine. Used to reserve an SVC number or for compatibility. |
When VSAM code issues an SVC, it does not pass the SVC number in a register as data—the number is in the instruction. But the SVC routine needs to know what to do: which file, which operation (read, write, etc.), and where the buffers are. That information is passed in a parameter list. For VSAM, the Request Parameter List (RPL) describes the request: it points to the ACB (Access Control Block) that identifies the cluster, specifies the operation (e.g. get sequential, put with key), and contains or points to the buffer addresses and lengths. The SVC routine uses the RPL to find the ACB and the buffers, performs the I/O (possibly issuing further SVCs or channel programs), and posts completion (e.g. by setting a return code or signalling the wait). So the SVC is the gate into supervisor state; the RPL (and related control blocks) tell the routine what I/O to perform.
Understanding that VSAM I/O goes through an SVC helps you see why certain operations are "supervisor" and why you cannot do raw I/O from a normal application. It also explains why debugging or tracing VSAM I/O often involves looking at SVC intercepts or supervisor-state traces. From a performance perspective, the cost of an SVC (the switch to supervisor state and the dispatch to the routine) is usually small compared to the actual I/O wait. The real time is spent waiting for the channel and device to complete the read or write. So the SVC is the doorway; the actual delay is in the I/O itself and in any wait/task synchronization (e.g. WAIT macro or equivalent) that blocks the task until the I/O completes.
Installations can define their own SVCs in the 200–255 range. These are used by subsystems such as IMS, CICS, or sort products. A user SVC might call VSAM or other access methods from supervisor state, or it might implement custom logic. As a VSAM application programmer you do not normally define an SVC; you use the standard VSAM interfaces (ACB, RPL, and the language-specific wrappers). The SVC that your call eventually triggers is part of the system or product that implements VSAM.
Imagine you are not allowed to touch the toy box (the disk) yourself—only the teacher (the operating system) can. When you want a toy (a record), you raise your hand and say a number (the SVC). The teacher looks at the number, goes to the toy box, gets the toy, and gives it to you. The number tells the teacher which rule to follow. The SVC is like raising your hand with that number: it lets the "teacher" (supervisor code) do the work that you are not allowed to do yourself.
1. What does SVC stand for?
2. Where does the SVC number come from?
3. Why does VSAM need SVC?