CORBA 2.6.1 Programmer's Guide for Java

"Error writing to CustDB");
...
}
How the Error Logging Facility Works
The public API section of the error logging facility is based on the severity levels of the messages you log: Critical, Error, Warning, or
Informational. These severity levels are reflected in the methods defined in the
com.tandem.nsdom.Config.Config_Log class, as shown in the
following code.
//com.tandem.nsdom.Config.Config_Log Class
public class Config_Log
extends java.lang.Object {
public static void log_critical(java.lang.Class pp_src_class,
int pv_src_line_num,
int pv_err_num,
java.lang.String pp_text)
public static void log_critical(int pv_err_num,
java.lang.String pp_text)
public static void log_critical(int pv_sc,
int pv_err_num
java.lang.String pp_text)
public static void log_error(java.lang.Class pp_src_class,
int pv_src_line_num,
int pv_err_num,
java.lang.String pp_text)
public static void log_error(int pv_err_num,
java.lang.String pp_text)
public static void log_error(int pv_sc,
int pv_err_num
java.lang.String pp_text)
public static void log_info(java.lang.Class pp_src_class,
int pv_src_line_num,
int pv_err_num,
java.lang.String pp_text)
public static void log_info(int pv_err_num,
java.lang.String pp_text)
public static void log_info(int pv_sc,
int pv_err_num
java.lang.String pp_text)
public static void log_warning(java.lang.Class pp_src_class,
int pv_src_line_num,
int pv_err_num,
java.lang.String pp_text)
public static void log_warning(int pv_err_num ,
java.lang.String pp_text)
public static void log_warning(int pv_sc ,
int pv_err_num
java.lang.String pp_text)
public static void set_component_name(java.lang.String pp_comp_name)
public static void set_log_file_name(java.lang.String pp_file_name)
}
Using the Trace Facility
Distributed applications typically involve interactions between a number of processes. When problems occur, you might wish to be able to gain
insight into these dynamic interactions. The NonStop CORBA trace facility is provided for this purpose.
Using the trace facility helps you to narrow the problem area to a specific set of interactions. For example, a client might send a request to an
object and never receive a reply. In this case, focusing more narrowly on the server hosting the object should prove fruitful. NonStop CORBA
provides tracing for a number of internal components, which you can control by using specific trace settings. However, you should be judicious in
enabling tracing because the volume of output can be large.
The NonStop CORBA trace facility provides an API that writes trace messages to an ASCII file. You
can use the trace facility to implement
instrumentation in your NonStop CORBA applications. You can add trace statements to specific portions of NonStop CORBA applications or
components to help troubleshoot program code.
Design of the Trace Facility
The trace facility consists of a single class called com.tandem.nsdom.Config.Config_Trace. This object provides several methods that write trace
messages out to a specified trace file. The methods shield you from the details of writing trace messages; you need not be concerned with the
details of the trace-file format, opening and closing the trace file, or any platform-specific issues.
When called, the trace facility composes a message based on both user-supplied data and data that the system obtains during the call. The
trace facility then writes the message out to a specified ASCII trace file. The trace facility is designed so that more than one process can write
trace information to a trace file.
The configuration database specifies the file to which the trace facility writes. By default, the trace facility writes to
stdout. If a trace message is
generated before
org.omg.CORBA.ORB.init() is called, the trace facility also writes to stdout. You can change the location either by using the