CORBA 2.6.1 Programmer's Guide for Java
Business domains
are collections of related business application processes, configuration data, and NonStop services for CORBA.
You can identify the business domains by using the Console.
The NSDAdminServer process provides services that are independent of any security domain, such as system configuration
information.
The NSDEnvironServer process provides services for a specific security domain.
The $NSD_ROOT/etc/env.sh file contains the environment settings.
The Configuration database (nsdcfgdb) contains entities for ORB components and application profiles.
The adminDB stores the operational data used by the NSDAdminServer and NSDEnvironServer processes. The location of the
database is given by the environment variable NSDOM_ADMIN_DB.
Using the NonStop Distributed Component Console
Many NonStop CORBA administration and configuration tasks can be performed using the NonStop Distributed Component Console. See the
NonStop CORBA 2.6.1 Administration Guide for basic information on using the Console. Using the Console you can start and stop the NonStop
CORBA environment, and you can configure individual profiles for the following services and objects:
General environment configuration such as names and directories
Bootstrap Service Daemon (BSD)
Comm Servers
Event Service
Interoperable Location Service Daemon (ILSD)
Interface Repository (IRD)
Location Service Daemon (LSD)
Naming Service
Object Transaction Service (OTS)
OTS Transaction ID Broker (XID)
When you use the Console to make configuration changes, it stores the changes in the configuration database. The Console software also
checks entries to make sure they fall between allowed ranges. If you change one field in the Console screens that has dependencies on other
fields, the Console will either automatically make changes to the other fields or leave them blank, prompting you to fill in a value.
You can also change the configuration database directly from the OSS environment command line, by using the Configuration Management Tool
(
cfgmgt). For information on how to use cfgmgt see the NonStop CORBA 2.6.1 Administration Guide. When you alter the configuration database
without using the Console, you need to understand the dependencies between the database entities and make your changes carefully to keep
your configuration working correctly.
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.1 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 when it is a direct TCP server (that is, tcp_server_true, but not
use_comm_server), or when 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, when the IDL
any type is used, you can start your NonStop
-ORBlimit recursive typecodes -ORBlimit recursive typecodes