Interrupt Handling In eMS CMS receives virtual SiC, input/output, program, machine, and external
interruptions and passes control to the appropriate handling program. SVC Interruptions
The Conversational Monitor System is SVC (supervisor call) driven. SVC interruptions are handled by the DMSITS resident routines. Two types of SVCs are processed by DMSITS: internal linkage SVC 202 and 203, and any
other SVCs. The internal linkage SiC is issued by the command and function programs of the system when they require the services of other CMS programs. (Commands entered by the user from the terminal are
converted to the internal linkage SVC by DMSINT). as SVCs are
issued by the processing programs (for example, the Assembler).
INTERNAL LINKAGE SVCS When DMSITS receives control as a result of an internal linkage SVC (202 or 203), it saves the contents of the general registers, floating-point
registers, and the SVC old PSW, establishes the normal and error return
addresses, and passes control to the specified routine. (The routine is
specified by the first 8 bytes of the parameter list whose address is
passed in register 1 for SVC 202, or by a halfword code following SVC 203. )
For SVC 202, if the called program is not found in the internal
function table of nucleus {resident} routines, then DMSITS attempts to
call in a module (a CMS file with file type MODULE) of this name via the LOADMOD command.
If the program was not found in the function table, nor was a module
successfully loaded, DMSITS returns an error code to the caller.
To return from the called program, DMSITS restores the calling
program's registers, and makes the appropriate normal or error return as
defined by the calling program. OTHER SVCs The general approach taken by DMSITS to process other SVCs supported
under CMS is essentially the same as that taken for the internal linkage SVCs. However, rather than passing control to a command or functiorr program, as is the case with the internal linkage SVC, DMSITS passes
control to the appropriate routine. The SVC number determines the
appropriate routine.
In handling non-CMS SiC calls, DMSITS refers first to a user-defined SVC table (if one has been set up by the DMSHDS program). If the
user-defined SVC table is present, any SVC number (other than 202 or 203) is looked for in that table. If it is found, control is
transferred to the routine at the specified address. CMS Introduction 2-7

If the SVC number is not found in the user-defined SVC table (or if
the table is nonexistent), DMSITS either transfers control to the CftSDOS shared segment (if SETDOS ON has been issued), or the standard system
table (contained in DMSSVT) of OS calls is searched for that SVC number. If the SVC number is found, control is transferred to the corresponding
address in the usual manner. If the SVC is not in either table, then
the supervisor call is treated as an abend call.
The DMSHDS initialization program sets up the user-defined SVC table.
It is possible for a user to provide his own SVC routines. Input/Output Interruptions
All input/output interruptions are received by the I/O interrupt
handler, DftSITI. DftSITI saves the I/O old PSi and the CSi (channel
status word). It then determines the status and requirements of the device the interruption and passes Lo the that
processes interruptions from that device. DMSITI scans the entries in
the device table until it finds the one containing the device address
that is the same as that of the interrupting device. The device table (DEVTAB) contains an entry for each device in the system. Each entry
for a particular device contains, among other things, the address of the
program that processes interruptions from that device. When the appropriate interrupt handling routine completes its
processing, it returns control to DMSITI. At this point, DftSITI tests
the wait bit in the saved I/O old PSi. If this bit is off, the
interruption was probably caused by a terminal (asynchronous) I/O operation. DftSITI then returns control to the interrupted program by
loading the I/O old PSi. If the wait bit is on, the interruption was probably caused by a
nanterminal (synchronous) I/O operation. The program that initiated the
operation most likely called the DMSIOi function routine to wait for a
particular type of interruption (usually a device end) • In this case, DMSITI checks the pseudo-wait bit in the device table entry for the
interrupting device. If this bit is off, the system is waiting for some event other than the interruption from the interrupting device; DftSITI returns to the wait state by loading the saved I/O old PSi. (This PSi has the wait bit on.)
If the pseudo-wait bit is on, the system is waiting for an
interruption from that particular device. If this interruption is not
the one being waited for, DMSITI loads the saved I/O old PSi. This will
again place the machine in the wait state. Thus, the program that is
waiting for a particular interruption will be kept waiting until that
interruption occurs.
If the interruption is the one being waited for, DftSITI resets both
the pseudo-wait bit in the device table entry and the wait bit in the I/O old PSi. It then loads that PSi. This causes control to be
returned to the DftSIOi function routine, which, in turn, returns control
to the program that called it to wait for the interruption.
2-8 IBM VM/370 System Logic and Program Determination--Volume 2