First-Level I/O Interrupt Processing

As just mentioned, the first-level I/O interrupt handler (FLIH) processes reflected interrupts from CP, saves information about the state of the interrupted program, and captures the interrupt status information relative to a XA or XC virtual machine. After the FLIH saves information about the interrupt, it looks for a second-level handler (SLIH) for the device that caused the interrupt. In general, the FLIH looks for a SLIH as follows:

1. The FLIH determines if a device path defined by the CONSOLE macro is waiting for the interrupt. If one is, the FLIH resets the appropriate wait bits and restarts the program (in this case, the console facility).
2. If a defined console path was not waiting for an interrupt, the FLIH looks for handler routines in the following order:
   1. Interrupt handling routines defined by HNDIO or HNDINT.
   2. OS/MVS STAX exit routines (for attention interrupts only).
   3. Exit routines defined by the CONSOLE macro. If the last path that performed I/O defined an exit routine, that exit routine gets control. If no path did I/O, the FLIH determines if the last path opened specified an exit routine. If it did, the FLIH passes control to it.

   Once fullscreen mode has been established using the CONSOLE macro, only attention interrupts will be passed to exits for the virtual console. Other interrupts (such as unsolicited device ends) may be passed to exits defined for dedicated 3270 devices.

3. If the interrupt is for the virtual console and no handler is found by the FLIH, then CMS performs standard processing for the virtual console.
4. Finally, if the FLIH still cannot find a handler, the interrupt is ignored and control is returned to the routine that was executing when the interrupt occurred.