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
Terminal Interruptions
Terminal input/output interruptions are handled by the DMSCIT module.
All interruptions other than those containing device end, channel end,
attention, or unit exception status are ignored. If device end status
is present with attention and a write CCW was terminated, its buffer is
unstacked. An attention interrupt causes a read to be issued to the
terminal, unless attention exits have been queued via the STAX macro.
The attention exit with the highest priority is given control at each
attention until the queue is exhausted, then a read is issued. Device
end status indicates that the last I/O operation has been co.pleted. If
the last 1/0 operation was a write, the line is deleted from the output
buffer and the next write, if any, is started. If the last IIO operation was a normal read, the buffer is put on the finished read list
and the next operation is started. If the read was caused by an
attention interrupt, the line is first checked for the commands RTI HC, OA, and the appropriate flags are set if one is found. Unit exception indicates a canceled read. The read is reissued, unless it
had been issued with ATTREST=NO, in which case unit exception is treated
as device end.
Reader I Pu nchl Pri nter I nterru ptions
Interruptions from these devices are handled by the routines that
actually issue the corresponding I/O operations. When an interruption
from any of these devices occurs, control passes to Then DMSITI passes control to DMSIOW, which returns contrel to the routine that
issued the I/O operation. This routine can then analyze the cause of
the interruption. User-Controlled Device Interruptions
Interrupts from devices under user control are serviced the same as CMS devices except that DMSIOW and DMSITI manipulate a user-created device
table, and DMSITI passes control to any user-written interrupt
processing routine that is specified in the user device table. Otherwise, the processing program regains control directly.
Program Interruptions
The program interruption handler, DMSITP, receives control when a
program interruption occurs. When DMSITP gets control, it stores the
program old PSi and the contents of the registers 14, 15, 0, 1, and 2
into the program interruption element (PIE). (the routine that handles
the SPIE macro instruction has already placed the address of the program
interruption control area (PICA) into PIE.) DMSITP then determines
whether or not the event that caused the interruption was one of those
selected by a SPIE macro instruction. If it was not, DMSITP passes
control to the DMSABN abend recovery routine.
If the cause of the interruption was one of those selected in a SPIE macro instruction, DMSITP picks up the exit routine address from the
PICA and passes control to the exit routine. Upon return from the exit
routine, DMSITP returns to the interrupted program by loading the
original program check old PSW. The address field of the PSi was
modified by a SPIE exit routine in the PIE. CMS Introduction 2-9
Previous Page Next Page