Supervisor Call instruction

In the System/360 line of IBM mainframe computers up to contemporary zSeries, a Supervisor Call instruction (SVC) is an instruction used to cause an interrupt in order to perform a Supervisor Call, which is distinct and separate from a system call, usually termed a Program Call (PC).

IBM mainframes in the System/360 and successor families operate in either of two states: problem state or supervisor state. Problem state relates to the set of non-privileged instructions which are available to solve the user's problem. In supervisor state, programs are additionally able to use privileged instructions which are unavailable in problem state, and which are generally intended for supervisory functions, e.g., for I/O.

The intended use of SVC is for the invocation of a defined supervisory function, which function is encoded in second byte of the SVC instruction, which has an instruction code of 0x0A, and a function code of 0x00 to 0xFF, with 0x00 (0) and upwards, roughly towards 0x7F (127), being defined by IBM, and with 0xFF (255) and downwards, roughly towards 0x80 (128), being defined by the user's system programmer (0 upwards to 199 and 255 downwards to 200 in z/OS). Return from the supervisory function which was invoked by the SVC instruction is effected by the privileged LPSW instruction which is invoked on behalf of the SVC routine by the SVC interrupt handler.

The description below is for illustrative purposes and applies to OS/360; some details changed in the progression from OS/VS2 Release 2 (MVS) to z/OS, while other operating systems, e.g., CP-67, TSS/360, do things very differently. However, a fundamental characteristic prevails in each of these system implementations: there is but one instruction, SVC, for all supervisor calls, which causes but one supervisor call interruption, and but one instruction, LPSW, that effects the return from a supervisor call interruption (or from any other interruption class for that matter). The return from a supervisory function may be immediate or delayed, depending upon the SVC Type and other considerations.

There are four standard types of SVCs in OS/360 and successors, known broadly as Types 1, 2, 3 and 4. Types 1 and 2 are always resident and are part of the nucleus. An example of Type 1 is SVC 10, used for both GETMAIN and FREEMAIN, which are the mechanisms to allocate an area of main storage to a task and to subsequently free it up, respectively. An example of Type 2 is SVC 42, ATTACH, which creates a new task, which may compete with other, existing tasks on a lower or higher priority basis. Type 1 does not use an SVRB (nor does MVS's Type 6), but Types 2, 3 and 4 do use an SVRB, which has obvious implications to the OS supervisor's dispatcher function. Types 3 and 4 are brought into the SVC "transient areas" as necessary (PLPA in post-MVT). An example is SVC 19, OPEN, which is used to make a dataset available for use by a user program. An installation can provide its own user-written SVCs, and these may also be Types 1, 2, 3 and 4 (and Type 6 in MVS).

OS/360 did not, in general, have any way of restricting the use of SVCs. Consequently, there were quite a number of unintentional system- and data-integrity exposures which were possible, when employing pathological sequences of certain SVCs and other instructions. It became common practice for users to attempt to discover these exposures, but some system programmers used these exposures rather than develop their own user-written SVCs. For example, it was possible, in pre-SVS, to simulate post-MVT's MODESET macro instruction, when using a common data management macro instruction and a few fictitious data structures.

With MVS/370, IBM mandated that all IBM SVCs be protected such that system- and data-integrity exposures were closed. IBM even "guaranteed" to close such exposures as these were discovered. And, by Release 3.7 of MVS/370 nearly every such exposure had indeed been identified and had indeed been closed. Of course, this required about 100,000 APARs and related PTFs. But, eventually, this mandate was indeed achieved. A remarkable achievement, as system "up time" was thereafter measured in years, rather than in days or even in hours.