At the risk of belabouring the point, the Error Message Service provides no callable facility
for delivering messages to the user, i.e. there is no analogue to ERR_FLUSH provided by
EMS for the programmer. This is a direct result of the binding of ERR to the particular
software environment being used. In the Error Message Service no such binding can be used
reliably. EMS is only able to stack and annul error messages and to control error deferral
using the same error table as the ERR subroutine library. Responsibility for the delivery of
error messages to the user therefore rests at a higher level, ultimately with the application
programmer.
Message delivery will usually be achieved by calling ERR_FLUSH at a higher level, or by ‘Message
Interception’ (see Section 7) but EMS has another feature which can be helpful in ‘stand-alone’
programs, i.e. without an environment present.
Outside any environment EMS has to have some reliable mechanism for ultimately delivering any
reported error messages to the user, since it cannot be guaranteed that the ERR library is being used at
the level of the application. This is achieved by the having the initial error context level of EMS deliver
any reported error message immediately to the user using a C printf statement: i.e. if all an
application does is call EMS_REP, then all error messages are immediately delivered to the user when
they are reported. Any higher error context level, set with a call to EMS_MARK or EMS_BEGIN, will have
the effect of deferring message output until the error reporting context is returned to its initial level
with calls to EMS_RLSE or EMS_END. Any deferred error messages will then be delivered to the user and
any further error messages reported in this context will again be delivered immediately to the
user.
The behaviour of EMS without an environment present means that it is essential for error reporting
contexts to be properly nested within a package and for a subroutine library using EMS not to exit at a
context level other than the one at which it was invoked. If context levels are incorrectly nested within
a package it can lead to EMS failing to deliver reported error messages when an application goes
wrong. Because the nested use of EMS_MARK and EMS_RLSE (or EMS_BEGIN and EMS_END) is normally
confined within the same routine, incorrect nesting of context levels will normally result from simple
programming errors which can be easily traced. However, there is no simple safeguard against the
incorrect nesting of error context levels provided by EMS: thorough testing is the most effective
approach.
N.B. On some systems, C and Fortran output cannot be reliably interspersed. This fallback
output at the EMS initial context level should therefore not be used in programs which also
use Fortran WRITE statements.
When using EMS from within an environment, the environment should ensure that the delivery of any reported error messages within the environment is deferred and that any undelivered messages are output to the user when the application has finished. There are three routines (actually part of the ERR library), exclusively for the use of environment implementors, which facilitate this task – they are discussed in Appendix C.