Approved for inclusion in a future ANSI M[UMPS] Language standard, as a part of the "event processing" extensions.
This command "blocks" an event. When an event is "blocked" for a process, that process will not be interrupted to execute code for that event when one occurs. If a registered event occurs for a process while it is "blocked", it will be queued for later processing. If an un-registered event occurs while it is "blocked", it will be ignored. Events are registered by assigning values to nodes in structured system variable ^$JOB. Events are "un-blocked" using the command AUNBLOCK.
Note: every ABLOCK command increases the "block" counter for an event. In order to "un-block" an event, every AUNBLOCK command decreases that counter. Events are only "un-blocked" when the value of that counter is equal to zero.
The example below assumes that the underlying system is capable of receiving a warning of imminent power loss from an "un-interruptible power supply" which is providing the system with power and that the system is capable of responding by generating an event. The event class in this case is "POWER", and the corresponding event-ID is equal to 1. A given process may want to execute a routine ^SHTDN to save its essential information if and when such an event occurs. The following code sample indicates how such an event can be processed asynchronously:
; Register the procedure to process a POWER event ; for this process SET ^$JOB($JOB,"EVENT","POWER",1)="^SHTDN" ; Enable this event for ; Asynchronous Event Processing ASTART "POWER"
From this point on, if the un-interruptible power supply generates the POWER event, this process will transfer control (asynchronously) to the routine ^SHTDN.
Now, keep in mind that event handling routines implicitly invoke an argumentless ABLOCK command when they are entered as the result of an event. When they exit, there is an implicit AUNBLOCK command for all events. In other words, while you're processing an event, you're temporarily blind to any events that might happen; this prevents getting yourself into an un-ending eddy of nested events. So, if this process also has handlers for other event classes that should be interrupted by POWER events, those event handlers should contain code like:
; Enable POWER events in this handler AUNBLOCK "POWER" ... ; the body of the event handles goes here ; Now block POWER events again, so that the ; implicit AUNBLOCK won't distort the "block-count" ABLOCK "POWER" QUIT
The above example shows processing of events of the class "POWER", The "event processing extension" defines the event classes "COMM" (events related to devices), "HALT" (events that are generated when processes terminate), "IPC" (events communicated by other processes), "INTERRUPT" (events that are generated when a process is interrupted in an implementation-specific fashion), "POWER" (events generated when loss of electrical power is imminent), "TIMER" (events that are generated when a timer's waiting time has elapsed) and "USER" (events that are generated through the ETRIGGER command).
This document is © Ed de Moel, 1995-2005.
It is part of a book by Ed de Moel that is published under
the title "M[UMPS] by Example" (ISBN 0-918118-42-5).
Printed copies of the book are no longer available.
This document describes the various commands that are defined in the M[UMPS] language standard (ANSI X11.1, ISO 11756).
The information in this document is NOT authoritative
and subject to be modified at any moment.
Please consult the appropriate (draft) language standard for an
authoritative definition.
In this document, information is included that will
appear in
future standards.
The MDC cannot guarantee that these 'next'
standards will indeed appear.