OSF DCE Application Development Guide--Core Components

Using the DCE Serviceability Application Interface
4.2.2 Components and Subcomponents
The very first step in incorporating serviceability into a server is to analyze it into
functionally discrete modules (called subcomponents), each of which will usually be
associated with a separate set of messages.
The program itself is regarded as the component. The main significance of
subcomponents is that each one uses a separate part of the message table generated by
sams, and every message is identified both by component and by subcomponent;
message routing and the level of debug messaging can be specified separately by
subcomponent.
4.2.3 Identifying Event Points
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 Section 4.3.1.
• 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
124245 Tandem Computers Incorporated 4− 15