craig@comp.lancs.ac.uk (Craig Wylie) (08/11/86)
A more specific question here, how can you catch signals (or their equivalent) in REXX, I know about the on interrupt or on error stuff. Does the interrupt exception handle both the situation where HI is typed on the terminal and where there is a system or operator generated signal (like kill in UNIX). I would like to trap these and perform some cleanup actions before going down. VM/CMS release 3. Craig. -- UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster, DARPA: craig%lancs.comp@ucl-cs | Department of Computing, JANET: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. Phone: +44 524 65201 Ext. 4146 | LA1 4YR Project: Cosmos Distributed Operating Systems Research Group
gelfand@valid.UUCP (Brooks Gelfand) (08/21/86)
> > A more specific question here, how can you catch signals (or their equivalent) > in REXX, I know about the on interrupt or on error stuff. Does the interrupt > exception handle both the situation where HI is typed on the terminal > and where there is a system or operator generated signal (like kill in UNIX). > > I would like to trap these and perform some cleanup actions before > going down. VM/CMS release 3. > > > Craig. > -- > UUCP: ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster, > DARPA: craig%lancs.comp@ucl-cs | Department of Computing, > JANET: craig@uk.ac.lancs.comp | Bailrigg, Lancaster, UK. > Phone: +44 524 65201 Ext. 4146 | LA1 4YR > Project: Cosmos Distributed Operating Systems Research Group The simple answer is you cannot in an unmodified VM operating system. Now that you have the simple answer, let's see why this is true. First, remember that as a VM user you are the operator of your virtual machine. The tube that you use to execute CMS commands is the system console for your virtual machine. There is very little the system operator of the real machine can do to programs running in your virtual machine; this is part of the beauty of VM. Of course he could always force your machine off. This is like pulling the power cord on a real machine. Not much chance to do any recovery or go down gracefully. Now let's look at your virtual machine (your logon). CMS is a single task, single user operating system that runs under the CP (Control Program) component of VM. REXX is the system interpreter that runs under CMS. There are three main ways you as the operator can cause a REXX program to terminate. You could press the PA1 key on the terminal to go to CP state and then IPL CMS or some other operating system. This is anologus to IPL (boot) the real hardware. There is no chance for REXX to even know that this has been done, much less trap any "signal". You could enter the immediate command HX which causes CMS to terminate any program, including REXX, running under it. You could enter the immediate command HI which causes REXX to halt execution. To see why REXX traps the HI command but not the HX command let's look at what happens when an immediate command is entered from the console. When the immediate command is entered, the console generates an interrupt. The interrupt causes the (virtual) hardware to load the IO NEW PSW and saves the current PSW in the IO OLD PSW. This action transfers control to module DMSITI. At label TRYREG in module DMSITI the correct interrupt routine is found in NUCON. Control is transfered to label FOUNDR where the IO OLD PSW and CSW are saved. DMSITI then passes control to the interrupt routine, in this case the console interrupt routine DMSCIT. DMSCIT reads the console input. Since this is a read with the attention bit set, control is transferred to label READFIN to check for an immediate command. After some housekeeping, control is passed to label BUILTIN to check to see if this is a standard immediate command; which both HI and HX are. If HX was entered, control is passed to label KILLX where the KXFLAG is set in FVSECT. If HI was entered, control is passed to label HLTEXEC where EXECFLAG is set in NUCON. At this point both routines transfer control to label FRETX which results in an eventual return to module DMSITI at label GO. DMSITI does some housekeeping and eventually arrives at label RETURN. Here a check is made to see if the KXFLAG is set. If the KXFLAG is not set (in the case where HI was entered), control is passed to label RETURNOK. Here all registers are restored and control is returned to to the module that was executing at the time of the interrupt by loading the saved OLD IO PSW that was saved by the routine at label FOUNDR. If the KXFLAG was set, control is passed to module DMSABN, the ABEND recovery module. This module closes all opened files, cleans up, and passes control back to CMS. REXX is not extered again and cannot process any signals or check any flags. Let us assume that the EXECFLAG is set and return if made to the REXX module that was executing at the time of the interrupt. Control will eventually return to module DMSRIN, the REXX master control module. In routine GOEXEC a check is made (via the SYSHALT macro) to see if the EXECFLAG is set. If a halt is indicated, control is passed to label GOHALT where a check is made to see if the ON HALT signal is enabled. If it is, control is passed to label GOSEARCH where the signal routine is found and executed; then REXX terminates. If the signal is not set, REXX terminates. All the source code examined was base source code for Release 3 of VM/SP with no fixes applied. Brooks Gelfand
barmar@mit-eddie.MIT.EDU (Barry Margolin) (08/27/86)
>... This is like pulling the power cord on a >real machine. Not much chance to do any recovery or go down gracefully. I'll bet the real IBM 370 has a power-fail interrupt. Does the virtual 370 have this? It seems like just the thing to use when the user aborts a program. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar