OSF DCE Application Development Guide--Core Components

Using the DCE Serviceability Application Interface
For example, developers should understand the implications of supplying function calls
as arguments to serviceability debug output routines (such as DCE_SVC_DEBUG). If
the debug code is compiled in (that is, if DCE_DEBUG is defined), then the
parameterized function calls will always be executed because the output routine itself
will still be called—even though it will produce no output.
In situations like this, the desirable course of action is simply to not call the output
routine at all if the currently set debug level has turned it into a no-op. This can be done
by using the DCE_SVC_DEBUG_ATLEAST macro to check the current level, as
shown in the following example:
if (DCE_SVC_DEBUG_ATLEAST(hel_svc_handle, hel_s_main, svc_c_debug3))
{
DCE_SVC_DEBUG((
hel_svc_handle,
hel_s_main,
svc_c_debug3,
" a_function_call() return value is: %s",
a_function_call(parm, status)));
}
The normal performance cost of a serviceability logging operation normally amounts to
one mutex lock and (usually) one file lock access per operation.
4.3.14 Usingthe Remote Serviceability Interface
Serviceability is primarily a mechanism intended to be used by servers. Like other
server functionality, it should be remotely controllable by properly authorized entities.
This allows such things as message routing and debug levels to be adjusted without
having to restart the server.
The standard remote serviceability interface is defined in the file
/usr/include/dce/service.idl.
An application server using serviceability is responsible for providing routines that
implement the operations defined in service.idl. However, ‘‘implementing’’ the
operations themselves is a simple matter of calling library routines that actually perform
them. The job of the application implementation is mainly to check the authorization of
the remote caller and then either reject the request (if authorization is found to be
insufficient) or call the appropriate library routine to perform the operation.
Table 4-3 lists such remote operations.
TABLE 4-3. Remote Operations by Application Servers
_______________________________________________________________________________
Server ‘‘Implementation’’ Library Routine Purpose
_______________________________________________________________________________
_______________________________________________________________________________
124245 Tandem Computers Incorporated 4− 39