OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
all errors. In this way a client need not concern itself with two or three separate error
parameters, and can use a consistent error handling scheme for both API and application
RPC errors. In order to return application-specific errors, such a status parameter must
be part of the IDL specification of the interface. The recommended method is therefore
to declare a status parameter as part of the application’s .idl file declarations, and then
add the [com_status] and [fault_status] attributes to the parameter by declarations in the
.acf file.
Of course, if application and DCE runtime errors are to share the same status parameter,
they must use disjoint error number spaces. The DCE messaging facilities provide a
means to do this.
7.2 Messaging Facilities
The need to acquire an error number space is related to the larger issue of messaging in
general. Applications typically need messages both for error reporting and for other
status reporting and informational purposes. The recommended practice is to use
messages catalogs for all messaging.
Message catalogs permit applications to deal with messages as numerical constants and
to keep all associated text separate from the application itself. This is especially
important for internationalization requirements; applications deal only with generic error
numbers; locale-specific message text is kept in separate catalogs.
Message numbers are partitioned by technology, component, and code. The technology
and component fields select a message catalog, and the code indexes messages within a
catalog. The requirement to have a unique application-specific error number space can
be met by adopting a unique component field within a given technology. To facilitate
this, OSF makes component numbers available in two ways.
1. Within the dce technology (the default core component technology field used by
DCE implementations), OSF sets aside two components guaranteed not to be used
by DCE implementations.
2. OSF sets aside an ISV technology and maintains a registry of component numbers
which may be assigned to ISVs.
This makes two levels of uniqueness available to applications. An unregistered
application can guarantee that its message number space does not conflict with that of
DCE implementations or of any registered ISV components by using one of the reserved
component numbers within the dce technology space. This does not, of course,
guarantee that the application’s message number space does not conflict with that of
other unregistered applications. This is a sufficient guarantee only for applications that
do not communicate or share application-specific message catalogs with other
unregistered applications. For example, the client side of an unregistered application
may encounter error number conflicts if it makes RPCs to the server side of an
application that uses an overlapping error number space.
Note: A related restriction on such non-registered applications is that they must
install their message catalogs in some application-specific place. Since
message catalog names depend on component numbers, other applications
7− 2 Tandem Computers Incorporated 124246