The interrupt handler is executed by GT.M when on a statement boundary or on an appropriate boundary in a potentially long running COMMAND (in the same place as <CTRL>-C is recognized). If a GT.M process is in a long running external call (for example; waiting in a message queue) the interrupt handler cannot be driven immediately. The interrupt request is recognized and the handler is driven after the external call returns to GT.M and an appropriate execution boundary is reached.

Since sending an interrupt signal requires the sender to have appropriate permissions from VMS, the use of the interrupt facility itself does not present any inherent security exposures. Nonetheless, because the dump files created by the default action contain the values of every local variable in the context at the time they are made, inappropriate access to the dump files would constitute a security exposure. Make sure the design and implementation of any interrupt logic includes careful consideration to security issues.

If an error occurs while compiling the $ZINTERRUPT code, the action taken depends on the process state at the time the interrupt was received and the error handler is not invoked (the error handler is invoked if an error occurs while executing the $ZINTERRUPT code). If the GT.M process is at a direct mode prompt or is executing a direct mode command (for example, a FOR loop), the error message is sent to the user console along with the GTM-ERRWZINTR error (refer to the GT.M Error and Message Recovery Manual). In addition, the GTM-ERRWZINTR error is also sent to the operator log facility. IF the process is not at a direct mode prompt or executing a direct mode command, the GTM-ERRWZINTR message and the compiler error message are sent to the operator log facility and nothing is displayed on the user's console. In both cases, the interrupted process resumes execution.

If an error occurs during execution of the interrupt handler's stack frame (before it calls anything), that error is prefixed with the GTM-ERRWZINTR error. The error handler then executes normal error processing associated with the module that was interrupted. Any other errors that occur in code called by the interrupt handler are handled by normal error handling. Refer to "Error Processing" chapter later in this manual.

If a TP transaction is in progress (0<$TLEVEL), updates to globals are not safe since a TP restart can be signaled at any time prior to the transaction being committed - even after the interrupt handler returns. A TP restart reverses all global updates and unwinds the M stack so it is as if the interrupt never occurred. The interrupt handler is not redriven as part of a transaction restart. Referencing (reading) globals inside an interrupt handler can trigger a TP restart if a transaction is active. When programming interrupt handling, either discard interrupts when 0<$TLEVEL (forcing the interrupting party to try again), or use local variables that are not restored by a TRESTART to defer the interrupt action until after the final TCOMMIT.

Note that it is possible for the interrupt handler to be executed while the process executing the M routine is holding the critical section for one or more regions. Use of this feature may create temporary hangs or pauses while the interrupt handler executes. For the default case where the interrupt handler uses $ZJOBEXAM() to create a dump, the pause duration depends on the number of local variables in the process at the time of the dump and on the speed of the disk being written to. The dumps are slower on a network-mounted disk than on a disk directly connected to the local system. Any interrupt driven code should be designed to account for this issue.