VMS Help
DECTPU, TPU$HANDLER
*Conan The Librarian (sorry for the slow response - running on an old VAX)
|
|
The TPU$HANDLER routine is the DECTPU condition handler.
The DECTPU condition handler invokes the $PUTMSG system service,
passing it the address of TPU$MESSAGE.
Format
TPU$HANDLER signal_vector ,mechanism_vector
OpenVMS usage:cond_value
type: longword (unsigned)
access: write only
mechanism: by value
Longword condition value. Most utility routines return a
condition value in R0. See Condition Values Returned.
signal_vector
OpenVMS usage:arg_list
type: longword (unsigned)
access: modify
mechanism: by reference
Signal vector. See the OpenVMS System Services Reference Manual
for information about the signal vector passed to a condition
handler.
mechanism_vector
OpenVMS usage:arg_list
type: longword (unsigned)
access: read only
mechanism: by reference
Mechanism vector. See the OpenVMS System Services Reference
Manual for information about the mechanism vector passed to a
condition handler.
The TPU$MESSAGE routine performs the actual output of the
message. The $PUTMSG system service only formats the message.
It gets the settings for the message flags and facility name from
the variables described in the OpenVMS Utility Routines Manual
in the section The DECTPU Shareable Image. Those values can be
modified only by the DECTPU built-in procedure SET.
If the condition value received by the handler has a FATAL status
or does not have the DECTPU facility code, the condition is
resignaled.
If the condition is TPU$_QUITTING, TPU$_EXITING, or TPU$_
RECOVERFAIL, a request to UNWIND is made to the establisher of
the condition handler.
After handling the message, the condition handler returns with
a continue status. DECTPU error message requests are made by
signaling a condition to indicate which message should be written
out. The arguments in the signal array are a correctly formatted
message argument vector. This vector sometimes contains multiple
conditions and formatted ASCII output (FAO) arguments for the
associated messages. For example, if the editor attempts to open
a file that does not exist, the DECTPU message TPU$_NOFILEACCESS
is signaled. The FAO argument to this message is a string for the
name of the file. This condition has an error status, followed by
the OpenVMS RMS status field (STS) and status value field (STV).
Because this condition does not have a fatal severity, the editor
continues after handling the error.
The editor does not automatically return from TPU$CONTROL. If
you call the TPU$CONTROL routine, you must explicitly establish a
way to regain control (for example, using the built-in procedure
CALL_USER). If you establish your own condition handler but call
the DECTPU handler for certain conditions, the default condition
handler must be established at the point in your program where
you want to return control. You can also interrupt TPU$CONTROL
by having your program specify and then trigger an asynchronous
routine via the TPU$SPECIFY_ASNYC_ACTION and TPU$TRIGGER_ASYNC_
ACTION routines.
See the OpenVMS Calling Standard for details on writing a
condition handler.
[legal]
[privacy]
[GNU]
[policy]
[netiquette]
[sponsors]
[FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.