6 Message Output

6.1 No EMS_FLUSH

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.

6.2 EMS without an environment

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.

6.3 EMS within an environment

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.