Once you have established the subcomponent organization of the server application, you can begin the work of identifying all the points in the server code at which events occur or can occur that require serviceability messaging.
Following is a list of the events and kinds of events that should be reported through the serviceability interface:
· Server startup
Servers should report when they are started, when they have completed their initialization, and when they are ready to perform work. They should also indicate when they are going offline.
· Server exit
All fatal exits should be reported as fatal errors, using the svc_c_sev_fatal severity attribute in a call to dce_svc_printf( ). In other words, exit( ) or abort( ) should not be called directly; this ensures that all such fatal errors will be logged. For an explanation of severity level attributes, see Basic Server Calls.
· Other fatal errors
Errors that make it impossible to proceed should be detected as close as possible to the point where the actual failure occurred. This class of error includes such "impossible" conditions as failure to successfully allocate memory, failure to open a configuration file for reading, failure to open a log file for writing, and so on.
· Impaired efficiency
Conditions that may indicate system-level malfunction or poor performance should be reported as warnings. An example of such a situation (from one of the DCE components) would be the RPC runtime detecting that it is having to make an excessive number of retransmits.
· Significant "routine" activity
Routine administrative actions should be reported as informational (svc_c_sev_notice) messages. Such activity includes creation, modification and deletion of tickets, threads, files, sockets, RPC endpoints, or other objects; message transfer, including name lookup, binding, and forwarding; directory maintenance (including caching, advertising, skulking, and replication); and database maintenance (including replication or synchronization).
· Data input syntax errors
Routines that process data that could have been entered from a keyboard should fail gracefully (and not core dump, for example) if the data is syntactically incorrect. Serviceability can be used to report this kind of failure.
Once you have identified the points in your code that should be reported with serviceability messaging, the next step is to define the messages themselves (in the sams file) and code the serviceability calls. The serviceability features of sams files were described previously; the following topics describe the various parts of the serviceability interface itself.
Using the serviceability interface to report errors ensures that the error codes used will be unique within DCE.