View source for Supervisor Call instruction

{{short description|Hardware instruction in the System/360 family of IBM mainframe}}
: ''This article covers the specific instruction on the IBM System/360 and successor [[Mainframe computer|mainframe computer]]s, 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 [[Company:Amdahl Corporation|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)<ref>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)</ref> and M200 (MP), and others; and is also used in the Hercules open source [[Mainframe computer|mainframe]] emulation software. It causes an interrupt to request a service from the [[Operating system|operating system]].  The system routine providing the service is called an ''SVC routine''.  SVC is a [[System call|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{{efn|I.e, all of the storage in address spacess accessible by the current ''dispatching unit''.}} 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{{efn|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.}}{{efn|several system libraries were always implicitly part of the concatenation}} 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 [[Supervisor Call instruction#OS/360 SVCs|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|hexadecimal]] [[Opcode|operation code]] {{mono|0A}}; the second byte of the instruction, the ''SVC number'',  indicates the specific request.<ref>{{cite book|last=IBM Corporation|title=IBM System/360 Principles of Operation|pages=72|url=http://www.bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf}}</ref> 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{{efn|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.|name=real}} 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{{efn|name=real}} 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{{efn|name=real}} address 35 on the 360 and 370, 323 on the z/System) contain the Supervisor call number.

SVC invokes a supervisory function&mdash;usually implemented as a "closed subroutine" of the system's SVC [[Interrupt handler|interrupt handler]].  Information passed to and from the SVC routines is passed in [[Processor register|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 [[Scheduling (computing)#Dispatcher|dispatcher]]<!-- E.g., POST may require dispatch of a higher priority task --> 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 [[Software:Time Sharing Operating System|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 [[Company:Fujitsu|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.  [[Software:VM (operating system)|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.

{| class="wikitable" 
|-
! 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<br>≤ 1024&nbsp;bytes || Each load module<br>≤ 1024&nbsp;bytes
|-
| Size of routine (OS/VS1) || {{Any}} || {{Any}} || Single load module<br>≤ 2048&nbsp;bytes || Each load module<br>≤ 2048&nbsp;bytes
|-
| Size of routine (SVS, MVS) || {{Any}} || {{Any}} || {{Any}} || {{Any}}
|-
| Refreshable  || {{No}} || {{No}} || {{Yes}}{{efn|name=FLPA|Resident SVC routines in OS/360, OS/VS1 and SVS need not be refreshable<br>SVC routines in FLPA need not be refreshable.}} || {{Yes}}{{efn|name=FLPA}}
|-
| Reenterable routine || {{Optional}}, but must be serially reusable || {{Yes}} || {{Yes}} || {{Yes}}
|-
| May allow interruptions || {{No}}{{efn|In MVS a Type 1 SVC holds the Local lock and may take interrupts.}} || {{Yes}} || {{Yes}} || {{Yes}}
|-
| Register contents at entry || colspan="4" | Registers{{efn|
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
}} 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 || {{CNone|None}} || colspan="3" {{Any}}
|-
| May issue WAIT || {{No}} || colspan="3" {{Yes|align=left}}, using "WAIT" (SVC 1)
|-
| May issue POST || {{Yes|align=left}}, but must use "Post" disabled branch entry || colspan="3" {{Yes|align=left}}, using "POST" (SVC 2)
|-
| May schedule synchronous exits || {{Yes|align=left}}, but must use "Exit Effector" disabled branch entry || colspan="3" {{Yes|align=left}}, using "SYNCH" (SVC 12)
|-
| May schedule abnormal termination || {{Yes|align=left}}, using "Abterm" disabled branch entry<ref>ABEND may be employed, but this is not considered best practice.</ref>  || colspan="3" {{Yes|align=left}}, using "ABEND" (SVC 13)
|-
|+ style="caption-side:bottom" | {{nobold|Table condensed from IBM System/360 Operating System System Programmer's Guide C28-6550-2<ref>{{cite book|last=IBM Corporation|title=IBM System/360 Operating System System Programmer's Guide|year=1967|url=http://www.bitsavers.org/pdf/ibm/360/os/R01-08/C28-6550-2_OSsysPrmg_Mar67.pdf}}</ref>{{rp|p.33}} }}
|}

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|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 [[Execute Channel Program|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|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==
{{Notelist}}

==References==
{{Reflist}}

==Further reading==
* {{Cite book|url=https://books.google.com/books?id=_ykfBAWBkxoC|title=Computer Architecture and Implementation|first=Harvey G.|last=Cragon|date=August 23, 2000|publisher=Cambridge University Press|isbn=9780521651684|via=Google Books}}
* {{Cite book|url=https://books.google.com/books?id=V1nm8afo9TEC|title=Schaum's Outline of Operating Systems|first=J. Archer|last=Harris|date=December 21, 2001|publisher=McGraw Hill Professional|isbn=9780071394482|via=Google Books}}

{{DEFAULTSORT:Supervisor Call Instruction}}
[[Category:IBM mainframe operating systems]]
[[Category:System calls]]

{{Sourceattribution|Supervisor Call instruction}}