CORBA 2.3.3 Programmer's Guide for C++ (NonStop CORBA 2.3.3+)
Table Of Contents
- CORBA 2.3.3 Programmer's Guide for C++
- Legal Notice
- Contents
- About This Guide
- Chapter 1. Introduction to NonStop CORBA Programming
- Chapter 2. NonStop CORBA Administrative Environment
- Chapter 3. Compiling and Building an Application
- Chapter 4. Deploying a NonStop CORBA Application
- Chapter 5. Tracing and Debugging Applications
- Chapter 6. Writing Scalable Applications
- Chapter 7. Managing Transactions
- Chapter 8. Writing Multithreaded Applications
- Chapter 9. Designing Advanced Applications
- Chapter 10. Porting CORBA Applications to NonStop CORBA
- Chapter 11. Writing Wrappers for Legacy Clients and Servers
- Appendix A. Architectural Walkthrough
- Appendix B. Object References
- Appendix C. Servant Reference Counting in NonStop CORBA
- Index

Viewing the Naming Service
Using the Console to View the Naming Service
Setting Up ns_browse to View the Naming Service
The ns_browse Tool Syntax
Examples of ns_browse Commands
Troubleshooting Application Components
Troubleshooting a NonStop CORBA application or component involves evaluating information from the following
sources:
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 Himalaya software products used by NonStop CORBA, such as TS/MP,
Compaq 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 Compaq 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 Himalaya 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.