OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
Although the two interfaces, broadly speaking, do the same general thing (that is, write
messages), their functionality was designed to serve different needs, both of which occur
in most distributed applications. Nevertheless, either interface can be used more or less
exclusively of the other, if desired. Both interfaces use message catalogs (for the most
part) to generate output; the catalogs themselves are generated by sams during
compilation, as mentioned earlier.
The following sections describe some aspects of using the serviceability interface. Full
discussions of both interfaces can be found in the .
7.3 Serviceability and Logging
The DCE serviceability facilities allow server applications to display or log messages, to
control message routing, and to associate actions with messages. A remote
serviceability interface also makes it possible to control server message routing and
filtering via dcecp or from application management clients.
The serviceability mechanism is designed to be used mainly for server informational and
error messaging—that is, for messages that are of interest to those who are concerned
with server maintenance and administration (in the broadest sense of these terms). The
essential idea of the mechanism is that all server events that are significant for
maintaining or restoring normal operation should be reported in messages that are made
to be self-documenting, so that (provided all significant events have been correctly
identified and reported) users and administrators will by definition always be able to
learn what action they should take whenever anything out of the ordinary occurs. User-
prompted, interactive, client-generated messaging should be handled through the DCE
messaging interface.
Serviceability is also used by the DCE components (for example, DTS, CDS, and so
forth) themselves. Consistent use of the same message mechanism by DCE
implementations and applications should result in simplified DCE administration.
DCE components use the serviceability facilities according to the following guidelines;
it is recommended that DCE applications use them also.
• All servers should report when they are started, and when they have completed their
initialization and are ready to perform work. They should also indicate when they
are going off-line.
• All program exits should be reported as fatal errors. Similarly, all calls to abort( )
should be replaced by calls to dce_svc_printf( ) with the svc_c_action_abort action
attribute specified.
• Errors which make it impossible for the application to proceed should be reported as
close as possible to the point of occurrence. This includes such conditions as: failure
to allocate memory, failure to open a configuration file for reading, or a log file for
writing, and so on.
• Conditions which may indicate system-level malfunction or poor performance must
be reported.
7− 4 Tandem Computers Incorporated 124246