Supervisor Call instruction


A Supervisor Call instruction is a hardware instruction in the System/360 family of IBM mainframe computers up to contemporary zSeries, and M200 used to cause an interrupt to request a service from the operating system. The system routine providing the service is called an SVC routine. SVC is a specific implementation of a system call.

Rationale

IBM mainframes in the System/360 and successor families operate in one of two states: problem state or supervisor state and in one of sixteen storage access keys. In problem state, a large set of general purpose non-privileged instructions are available to a user program. In supervisor state, system programs are additionally able to use a small set of privileged instructions which are generally intended for supervisory functions. These functions may affect other users, other processors, or the entire computer system. In storage key 0 a program is able to access all of storage.
A program is only allowed to access specific supervisory functions after thorough authorization checking by the operating system: DEBCHK, TESTAUTH, and possibly additional tests. Programs which fail any of these tests are ABENDed, that is abnormally terminated and immediately cease processing. Some of these tests were not available in OS/360, but were added in OS/VS1, SVS or MVS/370, but all were available in MVS/370 or subsequent releases, and are still available to this day.
In OS/VS1, OS/VS2, MVS/370 and subsequent versions of the OS, the MODESET function obviated the need for many user-written SVCs as this system SVC accommodated both changes in mode and key in a single operation, and many user-written SVCs were originally intended for simple mode and key changes, anyway, and subsequently the only special requirement was that the jobstep be APF authorized and that the MODESET-invoking program be resident in a concatenation of libraries all of which were identified as authorized, and this secure approach was completely under the installation's control. This approach generally simplified user controls over authorization, although some simple changes to the application were thereby required. In general, user installations favored this approach, and the overall reliability of the system was significantly improved thereby.
Although mainframe applications are typically synchronous processes, the operating system itself is naturally asynchronous, although the system also supports many processes which are naturally synchronous. When an application requests a system service which is naturally asynchronous, such as input/output processing, a mechanism for synchronizing the application and the operating system must be employed. This essential mechanism is through functions which are built into the operating system, or are specifically supported by it, including: WAIT ; POST ; and SYNCH.
The OS/360 SVCs table below indicates the conditions under which these synchronizing facilities may be employed.

Implementation

SVC is a two byte instruction with the operation code of 0A0x; the second byte, the SVC number, indicates the specific request.
SVC invokes a supervisory function—usually implemented as a "closed subroutine" of the system's SVC interrupt handler. Information passed to and from the SVC routines is passed in general purpose registers or in memory.

Under IBM-developed operating systems, return from an SVC routine is, for type 2, 3 and 4 SVC routines, via an SVC 3 invocation, and for other SVC types by the privileged Load PSW instruction, and which is executed on behalf of the SVC routine by the control program's dispatcher or SVC interrupt handler.
On non-IBM developed operating systems such as MUSIC/SP developed by McGill University in Montreal, Canada for IBM mainframes, and for non-IBM mainframes, VS/9, developed by Univac for the UNIVAC Series 90 mainframe line, and the B800 operating system for Fujitsu's mainfames, all use the LPSW instruction to exit from a Supervisor Call.
In MVS/370 and later incarnations of the OS, branch and link entry points are alternatives to SVC invocations for supervisor mode routines.
In MVS/SP V1R3 and later incarnations of the OS, Program Call entries have augmented SVCs for invocations of many supervisory functions by both authorized and unauthorized programs; and some functions may only be invoked by branch or PC entries, e.g. Start Input/Output.
Different IBM operating systems have little compatibility in the specific codes used or in the supervisor services which may be invoked. VM/370 and z/VM systems use the DIAG instruction in a similar manner, and leave SVC for the use by operating systems running in virtual machines. Most OS/360 SVCs have been maintained for "legacy" programs, but some SVCs have been "extended" over the passage of time.

OS/360 and Successor System SVCs

In OS/360 and successor systems SVC numbers 0 through approximately 127 are defined by IBM, and 255 downwards are available for use by an installation's systems programming staff. z/OS changed this to SVC numbers 0 through approximately 200 for IBM, and 255 downwards for the installation, as additional system services, primarily in support of encryption/decryption, were being implemented by IBM using SVCs. SVC routines must have module names in a specific format beginning with IGC.
By system design, the term "disabled" means disabled for all interruptions except for machine check interruptions in pre-MVS/370 systems, and with the "local lock" being held, but not "disabled" for any interruptions in MVS/370 and all later systems. The former is physical disablement, the latter is logical disablement, as an address space's "local lock" has the same impact within its address space as physical disablement, but it has no impact on other address spaces.
OS/360 defined four types of SVC routines, called "Type 1" through "Type 4"; MVS/370 added an additional "Type 6", which is similar to "Type 1" except that the SVC routine is physically disabled. "Type 5" was neither defined nor implemented. The following information, part of a table for OS/360, augmented for MVS/370 and successor systems, gives an idea of the considerations involved in writing an SVC routine.
The size restrictions on types 3 and 4 SVC routines are necessary because they are loaded into designated "transient areas" when invoked.
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 by employing certain sequences of SVCs and other instructions. It became common practice for curious users to attempt to discover these exposures, but some system programmers used these exposures rather than develop their own user-written SVCs.
Beginning with MVS/370, IBM considered it a product defect if a system design error would allow an application program to enter supervisor state without authorization. They mandated that all IBM SVCs be protected to close all system- and data-integrity exposures. They "guaranteed" to close such exposures as these were discovered. By Release 3.7 of MVS/370 in 1977 nearly every such exposure had indeed been identified and closed, at the cost of 100,000 Authorized Program Analysis Reports and related Program temporary fixes. This was a remarkable achievement, as system "up time" was thereafter measured in years, rather than in days or even in hours.