CORBA 2.6.1 Programmer's Guide for C++

System exceptions raised by the NonStop CORBA run-time environment, reported to the client program.
Other exceptions, raised by object classes, reported to the client program.
Run-time errors logged as text in a specified log file, displayed on the standard output device, STDERR, or sent to the Event
Management Service (EMS). Generally, the log file contains information about unexpected error conditions encountered by the
NonStop CORBA run-time.
Event messages from other NonStop software products used by NonStop CORBA, such as TS/MP, HP NonStop Transaction
Management Facility (TMF), and NonStop TCP/IP.
NonStop CORBA traces, controlled by entries in the configuration database or by environment variable settings.
IOR information obtained by using the showior tool.
Event Service information obtained by using the esadmin tool.
Naming Service information obtained by using either the Console or the ns_browse tool, as described in Viewing the Naming Service.
Locating errors in any distributed object application can be difficult for three reasons:
The flow of control in an application can pass through many classes. To make it easier to isolate the class where an error occurred, you
can design application exceptions so they include information that identifies the class.
If an application communicates with remote components, even remote ORBs, reconciling the error information from all sources and
pinpointing interoperability problems can be difficult. Verify that all ORBs are CORBA compliant and obtain full documentation, including
interoperability and compliance information, for each ORB. If an application uses class libraries or frameworks provided by multiple
vendors, you also will need full documentation for those components.
Successful run-time operation of NonStop CORBA depends on the correct configuration of NonStop CORBA, as well as other HP
products used by NonStop CORBA. The corresponding components on remote systems must also be configured correctly. For example,
errors in the TCP/IP configuration can interfere with NonStop CORBA configuration and application execution.
Note that you can do some troubleshooting steps, such as checking and modifying configurations and viewing error messages, without
instrumenting your application. On NonStop systems, event messages and configuration files for different products can help you identify
configuration problems. Several products, including TCP/IP, also support tracing. In some cases, an operator must work with other operators on
remote systems to discover configuration mismatches.
For a more general understanding of NonStop CORBA component interactions, architecture, and message flows, see
Appendix A, Architectural
Walkthrough.
Using the Error Logging Facility
Unexpected conditions detected by NonStop CORBA can be logged through the Event Management Service (EMS) on NonStop systems.
Looking at the log messages is one of the first things to do when troubleshooting a problem. Often the source of a problem can be ascertained
readily from information contained in the log.
Refer to the EMS Manual for background information and usage questions about EMS.
When logging is directed to EMS, the NonStop CORBA error logging facility operates in an OSS environment and uses EMS to report log
information. The NonStop CORBA error logging facility provides an API that you use to write NonStop CORBA exceptions and error conditions
to an EMS collector.
You can configure log messages to go to
STDOUT, STDERR, a log file, or EMS. You can use the data recorded in the log file to help you track and
fix problems that occur during the execution of your NonStop CORBA applications.
The error logging facility shields you from the details of error logging. You need not be concerned with the error-log file format or with creating,
opening, and closing the error log.
Design of the Error Logging Facility
The error logging facility is implemented in the NSDOM_Error_Log object. This object provides several methods for logging error conditions. When
you call a method in
NSDOM_Error_Log, the method creates the log message and performs the appropriate operations to write the message to
the configured destination.
The error logging facility composes a log message based on both data you supply and data that NSDOM_Error_Log obtains during the call.
Note:
The error log is also used internally by NonStop CORBA; messages written to the error log by your calls will be
interspersed with messages generated by NonStop CORBA.
Each time a log entry is generated, the error logging facility writes an error message to the configured destination. You specify an alternate
collector as described in
Starting an Alternate NonStop CORBA Collector.
An EMS collector must be started before you can write to it. Refer to the EMS Manual for details about starting and running the EMS collector.
Information in the Error Log
Table 5.1. Error Log Information
Field Description Field Name