Supervisor Call instruction

IBM System/360 Supervisor Call (SVC)

Company type	Instruction set / Hardware instruction
Industry	Computing / Mainframe computers
Founded	1964
Headquarters	Armonk , United States
Products	Supervisor Call instruction for IBM System/360 and compatible mainframes

This entry focuses on the particular instruction set related to the IBM System/360 and its descendant mainframe computer models, as well as compatible systems. For a broader understanding of instructions used to invoke operating system services, see System call.

A Supervisor Call instruction (SVC) is a hardware-level instruction utilized by the System/360 series of IBM mainframe computers extending through modern zSeries models, including systems from Amdahl such as the 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M, and 5990A; also found in Univac 90/60, 90/70, and 90/80; Fujitsu’s M180 (UP) and M200 (MP); as well as within the open-source Hercules mainframe emulator. This instruction generates an interrupt to solicit a service from the operating system, with the handling routine referred to as an SVC routine. Essentially, SVC serves as a form of system call.

Rationale

IBM mainframes within the System/360 heritage function under two distinct states: problem state and supervisor state, each coupled with one of sixteen storage protection keys (ranging from 0 to 15). In problem state, user-level programs have access to a wide array of general-purpose but non-privileged instructions. Conversely, supervisor state permits execution of privileged instructions reserved for system-level operations impacting users, processors, or the entire computing environment. Storage key 0 allows unrestricted access to all addressable memory locations; other keys impose specific access limitations.

Authorization checks enforced by the operating system—such as DEBCHK (SVC 117) and TESTAUTH (SVC 119)—are mandatory before accessing supervisory functions to prevent unauthorized execution. Programs failing these validations are subject to ABEND (abnormal termination). Although some checks were introduced post-OS/360 in systems like OS/VS1, SVS, or MVS/370, these have been standard since MVS/370 and continue in use.

Starting with OS/VS1, the MODESET function (SVC 107) unified numerous user-created SVCs by managing transitions between problem and supervisor states alongside changes in storage keys within a single operation. This mechanism required that calling programs possess APF authorization—meaning they were linked with approved libraries—to maintain security under installation control. This consolidation streamlined authorization processes and enhanced overall system stability.

Mainframe applications generally operate synchronously; however, the operating system itself functions asynchronously while supporting synchronous tasks. For asynchronous operations such as input/output processing, synchronization tools like WAIT (which suspends an application until an event occurs), POST (which signals that an event has happened), and SYNCH (which switches modes while preserving system integrity) are employed to coordinate between application and OS activities.

The OS/360 SVCs table specifies scenarios where these synchronization mechanisms are applicable.

Implementation

The SVC instruction consists of two bytes: the first byte is a fixed hexadecimal opcode ; the second byte represents the SVC number, indicating the requested service. This number ranges from 0 to 255 and is defined by the operating system—for instance, IBM’s MVS assigns SVC 3 for program termination, whereas UNIVAC VS/9 and Fujitsu BS2000 use SVC 9 for similar purposes.

Upon execution of an SVC instruction, an interrupt is generated. The Program Status Word (PSW)—a privileged register containing details such as the current instruction address, privilege level bit, and storage key—is saved at a real memory address. Control then transfers to an address loaded into the PSW; bits 24–31 of the saved PSW hold the Supervisor call number.

The SVC triggers a supervisory operation—usually implemented as a "closed subroutine" within the system’s SVC interrupt handler—with parameters passed through general-purpose registers or memory locations.

In OS/360 and its successors, routines of types 2, 3, and 4 return control via an SVC 3 (EXIT) call; other routine types utilize the privileged Load PSW (LPSW) instruction executed by either the control program’s dispatcher or the SVC handler for returning.

Non-IBM operating systems such as McGill University’s MUSIC/SP for IBM mainframes, UNIVAC’s VS/9, and Fujitsu’s B800 similarly employ LPSW for exiting Supervisor Calls. The decision between returning via LPSW or alternative methods like subroutine returns depends on design considerations: LPSW offers superior execution speed but demands dedicated system testing, whereas subroutine returns facilitate easier testing and performance analysis.

From OS/360 onward, branch-and-link entry points act as alternatives to direct SVC calls for certain supervisor routines. Beginning with MVS/SP V1R3, Program Call (PC) entries complement SVCs for many supervisory functions; some operations—such as STARTIO—require branch or PC entries exclusively. This strategy aids in preventing IBM operating systems from running on unauthorized hardware platforms.

IBM operating systems differ considerably regarding their specific SVC codes and services. VM/370 and z/VM utilize the DIAG instruction in a similar role while reserving SVC usage for operating systems executing within virtual machines. Although most OS/360-era SVCs remain primarily for backward compatibility, some have been extended over time.

OS/360 and Subsequent System SVCs

Within OS/360 and its follow-on systems, IBM allocated SVC numbers ranging from 0 to roughly 127, while numbers from 255 downward were designated for installation-specific purposes. The z/OS environment extended the IBM-defined SVC range to nearly 200, incorporating additional functionalities such as encryption and decryption services. SVC routines are required to have module names beginning with IGC.

The interpretation of the "disabled" state differs depending on the system: earlier systems before MVS/370 physically inhibit interrupts except for machine checks, whereas MVS/370 and later versions employ a logical "local lock" that disables interrupts only within the confines of a single address space.

OS/360 classified SVC routines into Types 1 through 4, with MVS/370 introducing Type 6, which resembles Type 1 but is physically disabled. Type 5 was never implemented. The following table summarizes essential attributes relevant to system programming and performance evaluation:

Characteristics	Type 1/Type 6	Type 2	Type 3	Type 4
Part of resident control program	Yes	Yes	No	No
Routine size (OS/360)	Any size	Any size	Single load module ≤ 1024 bytes	Each load module ≤ 1024 bytes
Routine size (OS/VS1)	Any size	Any size	Single load module ≤ 2048 bytes	Each load module ≤ 2048 bytes
Routine size (SVS, MVS)	Any size	Any size	Any size	Any size
Refreshable capability	No	No	Yes	Yes
Reentrancy	Optional but must be serially reusable	Yes	Yes	Yes
Interrupt allowance	No	Yes	Yes	Yes
Register contents at entry	Registers
Contains relocatable data	Yes	Yes	No	No
Can transfer control to other SVC types	None	Any
May invoke WAIT instruction	No	Yes, using WAIT (SVC 1)
May invoke POST instruction	Yes, but must use "Post" disabled branch entry	Yes, using POST (SVC 2)
May schedule synchronous exits	Yes, requiring "Exit Effector" disabled branch entry	Yes, via SYNCH (SVC 12)
May schedule abnormal termination	Yes, through "Abterm" disabled branch entry	Yes, using ABEND (SVC 13)

The size constraints for Types 3 and 4 reflect their loading into specific transient areas such as PLPA in post-MVT systems.

To illustrate critical business functions:

• Type 1 example: SVC 10 ("REGMAIN") handles allocation and release of main storage, crucial for resource management.
• Type 2 example: SVC 42 (ATTACH) initiates new tasks, enabling multitasking capabilities.
• Type 3 example: SVC 33 (IOHALT) stops I/O operations on non-DASD devices; it was reclassified as Type 2 in OS/VS due to teleprocessing requirements.
• Type 4 example: SVC 19 (OPEN) provides dataset access for user applications and supports custom access methods via EXCP.
• Type 6 example: SVC 107 (MODESET) modifies system mode/key without locking mechanisms, facilitating secure transitions in system state.

Security

In OS/360, there were generally no limitations on the use of SVCs, which resulted in multiple unintentional vulnerabilities affecting system and data integrity. These weaknesses could be exploited through specific sequences involving SVCs and instructions. While some users investigated these security gaps, certain system programmers took advantage of them instead of developing tailored SVC routines.

With the introduction of MVS/370, IBM classified any design oversight that permitted unauthorized access to supervisor state as a product defect. The company enforced strict safeguards for all SVCs to prevent such security issues and pledged to address any newly discovered vulnerabilities promptly. By the time MVS/370 Release 3.7 was issued in 1977, nearly all these risks had been mitigated through the implementation of over 100,000 Authorized Program Analysis Reports (APARs) and Program Temporary Fixes (PTFs). This effort greatly enhanced system reliability, extending operational uptime from mere hours or days to multiple years.