Supervisor Call instruction

This article covers the specific instruction on the IBM System/360 and successor mainframe computers, and compatible machines. For the general concept of an instruction for issuing calls to an operating system, see System call.

A Supervisor Call instruction (SVC) is a hardware instruction used by the System/360 family of IBM mainframe computers up to contemporary zSeries, the Amdahl 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M, and 5990A, and others; Univac 90/60, 90/70 and 90/80, and possibly others; the Fujitsu M180 (UP) ^[1] and M200 (MP), and others; and is also used in the Hercules open source mainframe emulation software. It causes an interrupt to request a service from the operating system. The system routine providing the service is called an SVC routine. SVC is 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 (0 to 15). 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 addressable ^{[lower-alpha 1]} storage, otherwise it is limited to storage areas with a matching key. 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 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 (SVS), 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 changes in mode (problem state to supervisor state) and key (8-15 [ user ] to 0-7 [ system ] ) 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 ^{[lower-alpha 2] [lower-alpha 3]} 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 (temporarily halt application processing until an external event has occurred); POST (indicate occurrence of an external event so application processing may continue); and SYNCH (change system processing mode—supervisor to user and system key to user key—while preserving system integrity, and synchronously perform a function on behalf of the application, after which supervisor processing may continue).

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 hexadecimal operation code 0A; the second byte of the instruction, the SVC number, indicates the specific request. ^[2] The SVC number can be any value from 0 to 255, with the particular SVC number being up to the implementer of the operating system, e.g. on IBM's MVS, SVC 3 is used to terminate a program, while on the UNIVAC VS/9 and Fujitsu BS2000 operating systems, SVC 9 was used for the same purpose.

When a program issues an SVC, an interrupt occurs. The PSW, an 8-byte (on the System 360 and S/370) or 16 byte (on the z/System), privileged register containing, among other things, the current address of the instruction to be executed, the privilege bit (1 if privileged), and storage key, is saved at a real ^{[lower-alpha 4]} address. This is locations 32-39 on the 360 and 370; 320-335 on the z/System. The PSW is then loaded from a different real ^{[lower-alpha 4]} address ; it is 96-103 on the 360 and 370, 448-463 on the z/system. Execution resumes at the address that was loaded into the PSW. Bits 24-31 of the saved PSW (real ^{[lower-alpha 4]} address 35 on the 360 and 370, 323 on the z/System) contain the Supervisor call number.

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 OS/360 and successors, return from an SVC routine is, for type 2, 3 and 4 SVC routines, via an SVC 3 (EXIT) invocation, and for other SVC types by the privileged Load PSW (LPSW) 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 (from the TSOS operating system for the RCA Spectra 70 series computers) for the UNIVAC Series 90 mainframe line, and the B800 operating system (also developed from the TSOS operating system) for Fujitsu's mainframes, all use the LPSW instruction to exit from a Supervisor Call.

The choice on whether to have a supervisor call return to the calling program directly through an LPSW instruction or through some other means such as a subroutine return instruction or a supervisor call itself, is a matter of design. There is no obvious "right" way to do this; there can be reasons for both methods. Using an LPSW instruction to exit an SVC routine allows for faster execution, but means actual testing of the routine has to be done on a dedicated machine running the code as part of an actual operating system supervisor. If the code was written as an ordinary subroutine it can be tested in the same manner as any ordinary program and potentially deployed without having to modify it. It also would allow metrics to be measured, as to how long a supervisor call routine took to complete its task, allowing for analysis of routines that are excessively long in execution time (or, ones that are very fast).

In OS/360 and later incarnations of the OS, branch and link entry points are alternatives to SVC invocations for some supervisor mode routines. In MVS/SP V1R3 and later incarnations of the OS, Program Call (PC) 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. STARTIO. (This also has the advantage of preventing IBM operating systems from being run on non-IBM hardware.)

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.

Table condensed from IBM System/360 Operating System System Programmer's Guide C28-6550-2 ^{[4] : p.33}

Conventions	Type 1/Type 6	Type 2	Type 3	Type 4
Part of resident control program	Yes	Yes	No	No
Size of routine (OS/360)	Any	Any	Single load module ≤ 1024 bytes	Each load module ≤ 1024 bytes
Size of routine (OS/VS1)	Any	Any	Single load module ≤ 2048 bytes	Each load module ≤ 2048 bytes
Size of routine (SVS, MVS)	Any	Any	Any	Any
Refreshable	No	No	Yes [lower-alpha 5]	Yes [lower-alpha 5]
Reenterable routine	Optional, but must be serially reusable	Yes	Yes	Yes
May allow interruptions	No [lower-alpha 6]	Yes	Yes	Yes
Register contents at entry	Registers [lower-alpha 7] 3, 4, 5, 6, 7 and 14 contain communication pointers; registers 0, 1 and 15 are parameter registers.
May contain relocatable data	Yes	Yes	No	No
May pass control to what other types of SVC routines	None	Any
May issue WAIT	No	Yes, using "WAIT" (SVC 1)
May issue POST	Yes, but must use "Post" disabled branch entry	Yes, using "POST" (SVC 2)
May schedule synchronous exits	Yes, but must use "Exit Effector" disabled branch entry	Yes, using "SYNCH" (SVC 12)
May schedule abnormal termination	Yes, using "Abterm" disabled branch entry [3]	Yes, using "ABEND" (SVC 13)

The size restrictions on types 3 and 4 SVC routines are necessary because they are loaded into designated "transient areas" (PLPA in post-MVT) when invoked.

• An example of Type 1 is SVC 10, used for both GETMAIN and FREEMAIN, which allocates an area of main storage to a task and to subsequently release it, respectively. SVC 10 is known informally as "REGMAIN" as it exchanges parameters through general purpose registers, only, and can both GET and FREE storage. SVC 4 and SVC 5 can perform similar GET and FREE functions, respectively, but exchange parameters through in-storage parameter lists.
• An example of Type 2 is SVC 42, ATTACH, which creates a new task.
• An example of Type 3 is SVC 33, IOHALT, which terminates I/O operations on a non-DASD device. This SVC was changed to Type 2 in OS/VS as IOHALT is heavily utilized in many teleprocessing-based systems.
• An example of a Type 4 is SVC 19, OPEN, used to make a dataset available for use by a user program, which includes modules common to all access methods and calls additional modules specific to each access method. OPEN also supports datasets which are to be operated on by a "roll your own" access method, such as those which are accessed using EXCP.
• An example of Type 6 is SVC 107, MODESET, which obtains no locks, but is able to change system mode and system key, in accordance with passed parameters.

Security

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 (APARs) and related Program temporary fixes (PTFs). This was a remarkable achievement, as system "up time" was thereafter measured in years, rather than in days or even in hours.

Notes

1. I.e, all of the storage in address spacess accessible by the current dispatching unit.
2. Initially this meant that the jobstep program was linked with AC(1) and came from an authorized concatenation of libraries. TSO/E later added a facility for authorized TSO commands.
3. several system libraries were always implicitly part of the concatenation
4. That is, an address that is subject to prefixing but not to Dynamic Address Translation. IBM only uses the term absolute address for an address that is not subject to either DAT or prefixing.
5. Resident SVC routines in OS/360, OS/VS1 and SVS need not be refreshable
   SVC routines in FLPA need not be refreshable.
6. In MVS a Type 1 SVC holds the Local lock and may take interrupts.
7. SVC register usage in OS/360 and MVS is
   • R3 CVT address
   • R4 TCB address
   • R5 RB address
   • R6 entry point address (MVS only)
   • R7 ASCB address (MVS only)
   • R14 return address CVTEXIR or SVC SLIH

References

1. Assembler Instructions V1.3 User Guide, Fujitsu Solutions GmBH, https://bs2manuals.ts.fujitsu.com/download/manual/959.1 (PDF) June 2010, Page 167 (Retrieved November 9, 2020)
2. IBM Corporation. IBM System/360 Principles of Operation (PDF). p. 72.
3. ABEND may be employed, but this is not considered best practice.
4. IBM Corporation (1967). IBM System/360 Operating System System Programmer's Guide (PDF).

Further reading

• Cragon, Harvey G. (August 23, 2000). Computer Architecture and Implementation. Cambridge University Press. ISBN   9780521651684 – via Google Books.
• Harris, J. Archer (December 21, 2001). Schaum's Outline of Operating Systems. McGraw Hill Professional. ISBN   9780071394482 – via Google Books.