This document has so far discussed the use of EMS in a general context. In this section, specific differences between EMS and the ADAM versions of the Message and Error Reporting Systems, MSG and ERR, are presented.
In calls to the ADAM version of
ERR_REP, the error message name
PARAM is a globally unique
identifier for the error message text which corresponds to the message parameter of the error
message. The ADAM interface file can be used to associate this message parameter with
an error message, and only if this message parameter is not defined in the interface file
is the argument
TEXT used in the error report. When using
EMS_REP (or the deprecated
EMS_MLOAD) within the ADAM environment software, no access to the ADAM interface file
exists and so the error message given by the argument
TEXT is always used. The use of a
globally unique error message name is still recommended for reported error messages to
uniquely identify the error message text to the programmer, using the convention outlined in
The ADAM versions of MSG and ERR allow reference to ADAM program parameters within the
message text. Reference can be made either to parameter-keyword associations or to the name of an
ADAM data system object, data file or device associated with a parameter. In message text used in
calls to MSG and ERR routines these parameter associations are indicated by the percent, “%”, and
dollar, “$”, escape characters respectively. EMS does not have access to the ADAM parameter system
and so cannot refer to ADAM parameters in the text of messages. The escape characters “%”
and “$” are therefore treated literally as part of the message text in calls to
EMS_EXPND (or the deprecated
EMS_MLOAD), as they are in the stand-alone versions of MSG and
In the ADAM versions of MSG and ERR a reserved token, ‘STATUS’, can be used to insert the message associated with a status value. In EMS, as in the stand-alone versions of MSG and ERR, there are no reserved message tokens
Because there is no callable mechanism provided by EMS to deliver messages to the user, no message synchronising mechanism is provided by EMS.
There are three ERR routines which start up, clear and stop the Error Reporting System within the
ADAM fixed part to ensure that the delivery of any reported error messages is deferred and that any
messages pending output are delivered to the user when the application has finished. These
ERR_STOP – they are discussed in this document because
they are purely for system programming and will affect the use of EMS as well as ERR within
ERR_START has the effect of marking a new EMS context and thus deferring the delivery of any
reported error messages to the user. The new context is known as the default context.
ERR_CLEAR has the effect of returning the current error context to the ‘default’ level set by
and flushing any reported error messages to the user. Thus, the effect of any mismatched ‘mark’ and
‘release’ calls within an application is annulled.
ERR_STOP clears the error message table by calling
ERR_CLEAR and then returns the error reporting
context to the initial context level, i.e. the level prior to the call to
The use of these three routines is entirely reserved for starting up, clearing and stopping error reporting within the environment, e.g. the ADAM fixed part, and must not be used for any other purpose.
These routines exist only in the ADAM version of the ERR library and are linked using the procedure given in SUN/104.