*** Welcome to piglix ***

Supervisor call instruction


A Supervisor Call instruction (SVC) is a hardware instruction in the System/360 family of IBM mainframe computers up to contemporary zSeries (as well as non-IBM mainframe computers such as the Amdahl 470/V5, 470/V6, 470/V7, 470/V8, 580, 5880, 5990M, and 5990A, and others; Univac 90/60, 90/70 and 90/80, and possibly others; and the Fujitsu M180 (UP), and M200 (MP), and others) 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.

IBM mainframes in the System/360 and successor families operate in one of two states: problem state or supervisor state. 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. A program is only allowed to access specific supervisory functions after thorough authorization checking by the operating system: DEBCHK (SVC 117), TESTAUTH (SVC 119), 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 SVS or MVS/370, but all were available in MVS/370 or subsequent releases, and are still available to this day.

In MVS/370 and subsequent versions of the OS, the MODESET function (SVC 107) obviated the need for many user-written SVCs as this system SVC accommodated both change in mode (problem state to supervisor state) and changes in key (non-zero [ user ] to zero [ system ] ) in a single operation, and many user-written SVCs were originally intended for simple mode and key changes, anyway, and subsequently the only requirement was that the MODESET-invoking program be resident in a "link library" which was identified as an "authorized library", and this secure approach was completely under the installation's control. This link library could be the system's own link library, SYS1.LINKLIB, or a user's link library which was associated with SYS1.LINKLIB. This change generally simplified user controls over authorization, although some simple changes to the application were thereby required. In general, user installations favored this accommodation, and the overall reliability of the system was significantly improved thereby.


...
Wikipedia

...