Supervisor call instruction
Encyclopedia
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 SVC instruction
for all supervisor calls, which causes but one supervisor call interruption, and but one privileged instruction, LPSW, which effects the return from a supervisor call interruption (or from any other interruption class).
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 their own user-written resident 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 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 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 corresponding 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.
System/360
The IBM System/360 was a mainframe computer system family first announced by IBM on April 7, 1964, and sold between 1964 and 1978. It was the first family of computers designed to cover the complete range of applications, from small to large, both commercial and scientific...
line of IBM mainframe
IBM mainframe
IBM mainframes are large computer systems produced by IBM from 1952 to the present. During the 1960s and 1970s, the term mainframe computer was almost synonymous with IBM products due to their marketshare...
computers up to contemporary zSeries
ZSeries
IBM System z, or earlier IBM eServer zSeries, is a brand name designated by IBM to all its mainframe computers.In 2000, IBM rebranded the existing System/390 to IBM eServer zSeries with the e depicted in IBM's red trademarked symbol, but because no specific machine names were changed for...
, 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
System call
In computing, a system call is how a program requests a service from an operating system's kernel. This may include hardware related services , creating and executing new processes, and communicating with integral kernel services...
, 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
OS/360 and successors
OS/360, officially known as IBM System/360 Operating System, was a batch processing operating system developed by IBM for their then-new System/360 mainframe computer, announced in 1964; it was heavily influenced by the earlier IBSYS/IBJOB and Input/Output Control System packages...
; some details changed in the progression from OS/VS2 Release 2 (MVS)
MVS
Multiple Virtual Storage, more commonly called MVS, was the most commonly used operating system on the System/370 and System/390 IBM mainframe computers...
to z/OS
Z/OS
z/OS is a 64-bit operating system for mainframe computers, produced by IBM. It derives from and is the successor to OS/390, which in turn followed a string of MVS versions.Starting with earliest:*OS/VS2 Release 2 through Release 3.8...
, while other operating systems, e.g., CP-67
CP-67
CP-67 was the control program portion of CP/CMS, a virtual machine operating system developed for the IBM System/360-67 by IBM's Cambridge Scientific Center. It was a reimplementation of their earlier research system CP-40, which ran on a one-off customized S/360-40...
, TSS/360
TSS/360
The IBM Time Sharing System TSS/360 was an early time-sharing operating system designed exclusively for a special model of the System/360 line of mainframes, the Model 67. Made available on a trial basis to a limited set of customers in 1967, it was never officially released as a supported product...
, do things very differently. However, a fundamental characteristic prevails in each of these system implementations: there is but one SVC instruction
SVC
SVC or .svc may refer to:* A computer file extension used by Microsoft's Windows Communication Foundation to represent a service hosted by Internet Information Services* IBM SAN Volume Controller, a hardware and software storage virtualization solution...
for all supervisor calls, which causes but one supervisor call interruption, and but one privileged instruction, LPSW, which effects the return from a supervisor call interruption (or from any other interruption class).
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 their own user-written resident 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 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 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 corresponding 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.