CORBA 2.6.1 Programmer's Guide for C++

TACL prompt:
> EMSACOLL /NAME $xxx, NOWAIT/ BLOCKING OFF
For more information about starting the EMS collector, see the EMS Manual.
Note:
The variable
$xxx is the process name for the collector that you set using MY_COLLECTOR in the $NSD_ROOT/etc/env.sh
file or in log_file in the default@ORB entity in the configuration database.
Viewing NonStop CORBA EMS Messages
To view the NonStop CORBA EMS messages, you must enter the following commands at the TACL prompt:
> ADD DEFINE =_EMS_TEMPLATES, FILE $SYSTEM.ZORBSDK.newnres
> EMSDIST TYPE PRINTING, COLLECTOR $xxx, TEXTOUT $TERM1
where $TERM1 identifies a terminal of your choice.
Note:
The
ZORBSDK subdirectory in the example above is the Guardian subvolume where the SDK environment is
installed. If you are using the run-time kit, you should use
ZORBRTK instead. The variable $xxx is the process name
for the collector that you set using
MY_COLLECTOR in the $NSD_ROOT/etc/env.sh file or in log_file in the default@ORB
entity in the configuration database.
Examining EMS Messages
An entry from the EMS log looks like:
10:56 19MAR02 015,05,304 GIOP Proxy demarshal 0 profiles. Severity: Error,
Component: Application, PName: \ODIN.$:5:304, PId: 219086853, TId: 1,
File: proxy.cpp, Line: 388
The date and time of the event is given first. Because the log might contain many messages from a number of different processes, examining
EMS messages that were logged during a particular interval is a useful strategy. The second part contains the text error message
GIOP Proxy
demarshal 0 profiles, which provides information that can help you troubleshoot the problem.
Calling the Error Logging Facility
Each call to the error logging facility is made at one of four severity levels: Critical, Error, Warning, or Informational:
Critical indicates an error that could result in significant loss of, or damage to, your subsystem’s environment.
Error indicates an error occurred that might require some user action to fix the problem (for example, a configuration error).
Warning indicates an event occurred that might cause a problem in the future (for example, a database file is 90 percent full).
Informational messages are not error or warning related and can be used for instrumentation.
When a call is made to log a message, the error logging facility must write the data to the log file before it can return to the caller.
The error logging facility itself does not raise any exceptions or return any errors. If the error logging facility cannot write to the error log file, it
writes to the standard output (
STDOUT).
You can log run-time exceptions by placing calls to the error logging facility in the error-handling routines of your NonStop CORBA applications.
To ease the task of adding error-logging messages to your code, NonStop CORBA supplies several predefined macros, one for each severity
level. When using these macros, you must supply the following information to each error-logging call you make:
A unique error number that represents the error condition
User-supplied error text
For NSDOM_LOG_xxx_EXC, pass a C++ exception. For NSDOM_LOG_xxx_ENV, pass an environment variable.
Note that the location of the error (the source filename and line number) is added to the call when you use the predefined macros.
Predefined Macros
To simplify the error-logging process, NonStop CORBA provides the following error-logging macros. See Error Logging Example for an example
of how you can use these macros.
NSDOM_LOG_CRITICAL(pv_err_num, pp_text) ;
NSDOM_LOG_CRITICAL_EXC(pv_err_num, pp_text, pp_exc) ;
NSDOM_LOG_ERROR(pv_err_num, pp_text) ;
NSDOM_LOG_ERROR_EXC(pv_err_num, pp_text, pp_exc) ;
NSDOM_LOG_INFO(pv_err_num, pp_text) ;
NSDOM_LOG_INFO_ENV(pv_err_num, pp_text, pp_env) ;
NSDOM_LOG_SET_COMPONENT_NAME(pp_comp_name) ;
#define NSDOM_LOG_SET_LOG_FILE(pp_log_file_name) ;