CORBA 2.6 Programmer's Guide for C++

Note: You can set many configuration database entities by using the NonStop Distributed
Component Console. These database settings apply to all applications, unless overridden by
an application-specific configuration entity (that is, profile@ORB). Application-specific
entities are managed by using the cfgmgt tool. See Application Profiles: Configuring and
Managing an Application for more information.
Note: The Console is also useful when you troubleshoot your application. In addition to checking
configuration information, you can use the Console to aid in tracing of NonStop CORBA
processes (but not application processes). You can also use it to view and modify the Naming
Service. See How to Enable and Disable Tracing and Viewing the Naming Service for more
information.
Caution: Be very careful to keep changes made through the Console and changes made to the
$NSD_ROOT/bin/nsdstart script or $NSD_ROOT/etc/env.sh consistent with
your intentions. If you have used the Console to change trace settings, those changes will
not be reflected in scripts.
Running NSDAdminServer and NSDEnvironServer
The NSDAdminServer is started by the NonStop CORBA installer, and it must be running before you
can use the NonStop Distributed Component Console. If it is stopped for any reason, it must be restarted
as described in the NonStop CORBA 2.6 Administration Guide. The NSDEnvironServer is started on
demand by the NSDAdminServer, and you generally do not need to start it.
Application Profiles: Configuring and Managing an Application
To configure your application, you set up your application's profile (the profile@ORB database entity)
using the cfgmgt tool. You use the -ORBprofile profile argument to find an application's
configuration in the NonStop CORBA configuration database. More than one application may use a
given profile@ORB entity, but the entity may not be shared if it is a direct TCP server (that is,
tcp_server_true, but not use_comm_server), or if it is a TS/MP server in a different server
class. Also, applications obviously must not have any conflicting configuration needs in order to share a
profile@ORB database entity.
Note:
To enhance interoperability with other vendor's ORBs, if the IDL any type is used, you can
start your NonStop CORBA application by using the
-ORBlimit_recursive_typecodes flag. The
-ORBlimit_recursive_typecodes flag improves handling of marshalled typecode
indirections (which NonStop CORBA encodes by default).
If no -ORBprofile argument is passed in the run command to a NonStop CORBA application, the
default@ORB entity is used. This entity acts as a subsystem configuration domain for any settings not
found in an application's profile@ORB entity.
If you don't set them in the application's profile, the default@ORB entity sets the log filename, trace
filename, url_path name, and interface repository filename. See the NonStop CORBA 2.6 Administration
Guide for a complete listing of the default@ORB entity settings.