HP NonStop CORBA Administration Guide

Transcription

1 HP NonStop CORBA Administration Guide HP NonStop CORBA Administration Guide Part number: Published September Legal Notice Abstract This manual provides information for administrators on how to configure your system for HP NonStop CORBA The information provided focuses on the HP-specific implementation of the Object Management Group's CORBA standards. Product Version: HP NonStop CORBA C11 Table of Contents New and Changed Information About This Guide Who Should Read This Guide Organization of this Guide Manuals in the NonStop CORBA Set Notation Conventions 1. NonStop CORBA Architecture Distributed Object Computing Infrastructure Services Availability Scalability Data Integrity Tools NonStop CORBA Architecture The NonStop CORBA ORB GIOP and IIOP GIOP Over TS/MP Protocol GIOP Over Guardian File System Protocol IIOP over SSL Portable Interceptors Client/Server Process NonStop CORBA Remote Services Client System Configuration Database Comm Server Parallel Library TCP/IP Location Service Daemon (LSD) Interoperable Location Service Daemon (ILSD) Bootstrap Daemon (BSD) Interface Repository Database The Common Object Services Naming Service Event Service Transaction Service Transaction Manager (OTSTM)

2 2. System Management Two-Phase Commit Process Resource Managers Transaction Context Controlling Transactions Application Portability NSDAdminServer and NSDEnvironServer Purpose of NSDAdminServer and NSDEnvironServer Starting and Stopping NSDAdminServer Starting NSDEnvironServer Configuration Data Used by NSDAdminServer and NSDEnvironServer What You Need to Know 3. Configuration and Management Using the Console Overview of the Console Connecting to Host System Managing Business and Security Domains Security Domains Business Domains Monitoring the Servers Server Status Indicators Detailed Server Status Display Status Information for NSDAdminServer and NSDEnvironServer Controlling the Servers Starting the Servers Stopping the Server Stopping Managing the Servers Viewing and Configuring Server Properties General Properties Naming Service Properties Event Service Properties Object Transaction Service (OTS) Properties Object Transaction Service XID (OTSXID) Properties Location Service Daemon (LSD) Properties Bootstrap Daemon (BSD) Properties Comm Server Properties Viewing and Configuring Comm Server Mappings Displaying the Comm Server Map Adding a Comm Server Mapping Removing a Comm Server Mapping Managing Naming Service Data Displaying the Naming Service Hierarchy Adding a Naming Context Renaming a Naming Context or Name Removing a Naming Context or Name Viewing an Object Reference Saving an Object Reference Refreshing the Display

3 Using the Console to Troubleshoot the Servers Load Balancing 4. Configuration and Management Using Commands Configuration Setting Environment Variables (env.sh file) Customizing the env.sh file Configuration Database Configuration Management Tool (cfgmgt) Managing NonStop CORBA Processes Starting and Stopping NonStop Services for CORBA How the nsdstart Script Works Troubleshooting: Problems Starting NonStop Services for CORBA Differences Between Using Scripts and Using the PATHCOM Interface Customizing the nsdstart Script Configuring NonStop CORBA to Use Parallel Library TCP/IP Configuring the BSD, LSD and ILSD for Parallel Library TCP/IP Configuring a Comm Server for Parallel Library TCP/IP Configuring Additional Parallel Library TCP/IP Comm Servers Using the PATHCOM Interface to Maintain TS/MP Processes Using the PATHCOM Interface Starting a PATHMON Process Restarting a Previously Defined TS/MP Configuration Monitoring Status Displaying Configuration Information Displaying Status Information Displaying Statistical Information Modifying Global Parameters Based on Changing Requirements Reconfiguring Server Pools Adding a Server Pool Modifying Running Server Pools Altering a Server Pool Managing the Distributed Object Environment The Distributed Object Environment NonStop CORBA Configuration Management NonStop CORBA Performance Tuning NonStop CORBA Troubleshooting 5. Managing Application Processes The Application Environment Application Configuration Management Application Performance Tuning 6. Configuring Security Features IIOP/SSL Transport Protocols Configuring and Managing Private Keys and Certificates profile in env.sh newca Script newreq Script signreq Script pkcs12 Script

4 Configuring and Managing Security Unaware Applications Modifying the NonStop CORBA Configuration Configuring and Managing Security Aware Applications Operation with Comm Server, LSD, and Naming Service A. Configuration Database Entities Standard Entities Client and Server Protocol Specifications Client Protocols Server Protocols Protocols Common to both Clients and Servers JSSE Keystore JSSE Truststore OpenSSL Cipher List for Use with ssl_ciphers Pathsend Protocol File-System Protocol IIOP/SSL Protocol IIOP Protocol Indirect Server Protocol Keys and Values B. cfgmgt Command Reference bye, exit, quit cfgmgt dbcreate dbname dbremove dumpdb entities entity entityaddkeyvalue entitydelete entitydeletekey entitykeys entitykeysvalues profile source C. /bin Directory Files D. Log Files E. Troubleshooting Detecting and Fixing Problems with Running Applications

5 Cannot Start HP NonStop Console Cannot Start CORBA Server Shared Library ioser12 Could Not Be Found Cannot Stop CORBA Server Cannot Run Client (COMM_FAILURE) Verifying TCP/IP Configuration NonStop CORBA Listening on the Wrong Socket Index List of Figures 1.1. Basic NonStop CORBA Subsystems 1.2. NonStop CORBA Remote Services 1.3. Original TCP/IP 1.4. Parallel Library TCP/IP 1.5. Transaction Service Components List of Examples 4.1. Parallel Library TCP/IP LSD 4.2. Parallel Library TCP/IP BSD 4.3. Parallel Library TCP/IP Comm Server 6.1. Sample newca Run 6.2. Sample newreq Run 6.3. Sample signreq Run 6.4. Sample pkcs12 Run New and Changed Information

6 New and Changed Information New and Changed Information The updates in this edition ( ) are: In the section Customizing the env.sh file: SRL instances are modified to DLL The variable _SRL_01 is modified to _RLD_LIB_PATH The updates in this edition ( ) are: Note: The following updates are applicable only from T2817H14, T2818H14, and T2820H14 release onwards. This version of NS CORBA must be used on H06.26/J0.15 and later RVU s. Also, it requires NSJ7 (32-bit) application for further configurations. Current SPT library is replaced by PUT library (T1280). Softlink (/usr/tandem/java) is not created automatically in NSJ7 (32-bit) application. For more information on creating softlink on NSJ7 (32-bit) application see, NonStop Server for Java 7.0 Programmer s Reference. The updates in this edition ( ) are: Updated the description of Configuring and Managing Private Keys and Certificates. Updated the description of Activating the BSD Bootstrap Protocol. The updates in this edition ( ) are: Updated the description of Server Configuration Options. Updated the Note in the INFO PATHWAY Command section. The updates in previous edition ( ) were: Added the following new features for HP NonStop CORBA 2.6.1: Support for IIOP/SSL for JORB. Support for NonStop Server for Java 4.0. Support for Pthreads (T1248) used by NSJ 4.0. Support for HP Enterprise Toolkit (ETK) 2.0. Explanation on how to send the IP address to the client. All chapters contain minor technical and editorial corrections. HP NonStop CORBA Administration Guide About This Guide

7 Copyright 2009, 2014 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR and , Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor s standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Export of this documentation may require authorization from the U.S. Department of Commerce. Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation. Intel, Itanium, Pentium, and Celeron are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Motif, OSF/1, UNIX, X/Open, and the "X" device are registered trademarks, and IT DialTone and The Open Group are trademarks of The Open Group in the U.S. and other countries. Open Software Foundation, OSF, the OSF logo, OSF/1, OSF/Motif, and Motif are trademarks of the Open Software Foundation, Inc. OSF MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THE OSF MATERIAL PROVIDED HEREIN, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. OSF shall not be liable for errors contained herein or for incidental consequential damages in connection with the furnishing, performance, or use of this material. 1990, 1991, 1992, 1993 Open Software Foundation, Inc. This documentation and the software to which it relates are derived in part from materials supplied by the following: 1987, 1988, 1989 Carnegie-Mellon University. 1989, 1990, 1991 Digital Equipment Corporation. 1985, 1988, 1989, 1990 Encore Computer Corporation Free Software Foundation, Inc. 1987, 1988, 1989, 1990, 1991 Hewlett-Packard Company. 1985, 1987, 1988, 1989, 1990, 1991, 1992 International Business Machines Corporation. 1988, 1989 Massachusetts Institute of Technology. 1988, 1989, 1990 Mentat Inc Microsoft Corporation. 1987, 1988, 1989, 1990, 1991, 1992 SecureWare, Inc. 1990, 1991 Siemens Nixdorf Informationssysteme AG. 1986, 1989, 1996, 1997 Sun Microsystems, Inc. 1989, 1990, 1991 Transarc Corporation. This software and documentation are based in part on the Fourth Berkeley Software Distribution under license from The Regents of the University of California. OSF acknowledges the following individuals and institutions for their role in its development: Kenneth C.R.C. Arnold, Gregory S. Couch, Conrad C. Huang, Ed James, Symmetric Computer Systems, Robert Elz. 1980, 1981, 1982, 1983, 1985, 1986, 1987, 1988, 1989 Regents of the University of California.

8 Printed in the US Java is a registered trademark of Oracle and/or its affiliates.

9 About This Guide About This Guide Who Should Read This Guide Organization of this Guide Manuals in the NonStop CORBA Set Notation Conventions As originally installed, your NonStop CORBA system is fully functional, but you may wish to alter the configuration at some later time. The NonStop CORBA Administration Guide describes how to use the HP NonStop Distributed Component Console software to modify the configuration of your system. This guide includes information about the configuration files used and explains how to change configurations. The guide also shows you how to optimize your system, including how to customize the HP NonStop TS/MP processes running in the system. For users who prefer to use the command-line-based configuration tools, the guide gives instructions for using those techniques. This guide also contains information about the NonStop CORBA system architecture. Who Should Read This Guide This guide is intended for CORBA application developers who are familiar with NonStop systems and the HP NonStop Kernel operating system. Note: This guide describes only the NonStop server differences and additions that allow standard CORBA applications to work on the NonStop platform. The reader must be knowledgeable about Object Management Group s (OMG) CORBA standards and fully familiar with the OMG CORBA specifications, which are located at the following URL: Organization of this Guide Chapter 1, NonStop CORBA Architecture, introduces NonStop CORBA and describes its infrastructure. Chapter 2, System Management, describes the NSDAdminServer and the NSDEnvironServer, processes that provide support services. It also lists sources for general information that administrators need to know before attempting to manage a NonStop CORBA system. Chapter 3, Configuration and Management Using the Console, describes how to configure and manage NonStop Services for CORBA by using the NonStop Distributed Component Console. Chapter 4, Configuration and Management Using Commands, describes how to configure and manage NonStop CORBA by using a command interface. Chapter 5, Managing Application Processes, describes the application environment, configuration management, and performance tuning. Chapter 6, Configuring Security Features, describes configuring private keys and certificates, and configuring applications. Appendix A, Configuration Database Entities, is a reference for the standard configuration database entities in a NonStop CORBA configuration database. Appendix B, cfgmgt Command Reference, describes the commands available in the configuration management tool. Appendix C, /bin Directory, describes files that in the /bin directory of the product installation. Appendix D, Log Files, names the processes that generated log files Appendix E, Troubleshooting, provides links to parts of the NonStop CORBA that discuss troubleshooting. Manuals in the NonStop CORBA Set The NonStop CORBA Getting Started Guide for C++ describes how to install the product and verify installation for the C++ programming environment. It also includes an introduction to the product. The NonStop CORBA Getting Started Guide for Java describes how to install the product and verify installation for the Java programming environment. It also includes an introduction to the product. The NonStop CORBA Administration Guide gives basic configuration information and describes how to use the NonStop Distributed Component Console and the command-line interface to perform configuration tasks. The NonStop CORBA Programmer's Guide for C++ provides information for C++ application programmers about the HPspecific implementation of CORBA. NonStop CORBA Programmer's Guide for Java provides information for Java application programmers with special emphasis on the HP-specific implementation of CORBA. The NonStop CORBA Programmer's Reference provides information for both C++ and Java application programmers about the IDL compiler, other utilities, minor codes, and system errors. For C++ programmers, it serves as the reference complement to the

10 NonStop CORBA Programmer s Guide for C++. For Java programmers, it provides IDL to Java mapping. (Reference information for Java interfaces and classes is provided in Javadoc format on the product CD.) The NonStop CORBA Glossary provides definitions of CORBA terminology, with special emphasis on the NonStop CORBA implementation. In addition, the NonStop Distributed Component Console includes online help. Notation Conventions Syntax Item Bold text UPPERCASE LETTERS Italic letters Description Bold text in a paragraph indicates a technical term that is defined within the text and also, in some cases, in the NonStop CORBA Glossary. Uppercase letters indicate keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example: MAXATTACH Items in Italicletters indicate variable items that you supply. Items not enclosed in brackets are required. In the following example, UserDir is a variable directory name, while /projectx must be entered exactly as shown: UserDir/projectX [ ] Brackets enclose optional syntax items. For example: TERM [\system-name.]$terminal-name INT[ERRUPTS] A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list may be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: LIGHTS [ ON ] [ OFF ] [ SMOOTH [ num ] ] K [ X D ] address-1 { } A group of items enclosed in braces is a list from which you are required to choose one item. The items in the list may be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example: LISTOPENS PROCESS { $appl-mgr-name } { $process-name } ALLOWSU { ON OFF } A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example: INSPECT { OFF ON SAVEABEND }... An ellipsis immediately following a pair of brackets or braces indicates that you can repeat the enclosed sequence of syntax items any number of times. For example: M address-1 [, new-value ]... [ - ] { }... An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times. For example: "s-char..." - A dash in a command usually indicates a separate flag. " " When quotation marks surround a defined syntax symbol (such as a bracket or brace), they symbolize an actual character that must be entered as shown. For example: Other punctuation Long Commands "[" repetition-constant-list "]" Punctuation not previously described (such as parentheses, commas, and semicolons) must be entered as shown. For example: error := NEXTFILENAME ( file-name ) ; LISTOPENS SU $process-name.#su-name If the syntax of a command is too long to be shown on a single line, each continuation line is indented three spaces, the first of which is separated from the preceding line by a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections. For example: ALTER [ / OUT file-spec / ] CONTROLLER

11 [, attribute-spec ]... New and Changed Information Chapter 1. NonStop CORBA Architecture

12 Chapter 1. NonStop CORBA Architecture Chapter 1. NonStop CORBA Architecture Distributed Object Computing Infrastructure Services Availability Scalability Data Integrity Tools NonStop CORBA Architecture The NonStop CORBA ORB GIOP and IIOP GIOP Over TS/MP Protocol GIOP Over Guardian File System Protocol IIOP over SSL Portable Interceptors Client/Server Process NonStop CORBA Remote Services Client System Configuration Database Comm Server Parallel Library TCP/IP Location Service Daemon (LSD) Interoperable Location Service Daemon (ILSD) Bootstrap Daemon (BSD) Interface Repository Database The Common Object Services Naming Service Event Service Transaction Service Transaction Manager (OTSTM) Two-Phase Commit Process Resource Managers Transaction Context Controlling Transactions Application Portability Distributed Object Computing CORBA is the acronym for Common Object Request Broker Architecture, an architecture and set of specifications developed by the Object Management Group (OMG ). The Object Request Broker enables objects to transparently make and receive requests and responses in a distributed environment. It is the foundation for building applications from distributed objects. NonStop CORBA 2.6.1, which is based on OMG CORBA core specification and other OMG specifications, provides an infrastructure and development environment that enables system administrators and software developers to process and develop distributed object applications and components. These applications and components run on HP NonStop Kernel Open System Services (OSS). Language and object-adapter features enhance the portability of the components you write using NonStop CORBA. Client and server objects using NonStop CORBA offer the software developer and systems administrator the following benefits: Interoperation with other CORBA ORBs

13 Wide area network (WAN) and local area network (LAN) connectivity based on international networking standards Ability to wrap legacy applications with a distributed object architecture (an advantage of NonStop CORBA) Infrastructure The NonStop CORBA infrastructure provides the services and tools to help software developers and system administrators build object-oriented components and distributed object systems. These systems can be implemented at the application level, the system level, or as middleware software. Services NonStop CORBA is a robust implementation of Object Management Architecture (OMA) used in large-scale, enterprise-wide, mission-critical systems. The infrastructure combines the flexibility of object technology with the robustness of a transaction-processing monitor. Optimized for use in transaction processing, NonStop CORBA allows the mapping of a large number of clients to a smaller number of servers, effectively sharing resources. Because the NonStop CORBA system processes run in a TS/MP environment, you get the strength of HP NonStop transaction services in a CORBA environment. NonStop CORBA provides differentiation in the areas of availability, scalability, and data integrity (transaction protection) required for missioncritical applications. Availability To support continuous availability, an object-oriented runtime environment must provide fault tolerance on the following three levels: 1. The system platform 2. The ORB 3. The application components NonStop CORBA provides the first level of fault tolerance by running on the NonStop Kernel operating system, which offers such features as NonStop process pairs, mirrored disk controllers, and fault-tolerant communications subsystems. The ORB supports fault tolerance by using TS/MP as a process manager for ORB processes. TS/MP provides automatic restart when a server process fails. Automatic restart is also available to application components that use TS/MP server pools. Scalability Scalability allows a system to grow dynamically as usage increases. NonStop CORBA provides scalability in the following dimensions: Network connections Object Request Broker (ORB) processes Application processes Data Integrity In addition, NonStop CORBA ensures the integrity of its own data stores and offers an object transaction service you can use to maintain a secure environment for your applications. Tools NonStop CORBA provides software developers the ability to build object-oriented components and distributed object systems using either the C++ or Java programming languages. As CORBA is language independent, you can utilize the fast development aspects of Java along with the high performance characteristics enjoyed by C++. It is common for a user to first develop in Java, then if there are any performance bottlenecks, rewrite just those objects and components in C++. NonStop CORBA Architecture The NonStop CORBA architecture consists of component subsystems, NonStop Remote Services, NonStop Common Object Services, the NonStop Object Request Broker and the NonStop CORBA application servers that you create. Although the creation of CORBA objects is accomplished in a purely standard way, the execution and interaction of those objects are highly dependent upon the infrastructure an ORB vendor supplies. Figure 1.1. Basic NonStop CORBA Subsystems

14 The NonStop CORBA ORB The NonStop CORBA ORB, although conceptually a single entity, is actually a group of mechanisms. Among these are an SRL (Shared Runtime Library), databases, and the stubs and skeletons representing CORBA objects. The SRL contains mechanisms, which control all events, threads, database I/O, and the interaction the ORB requires to act as the object message bus, to assure delivery and proper system interaction. The stubs and skeletons contain the required code to marshal and demarshal the actual requests and their parameters. GIOP and IIOP Inter-ORB communications are accomplished through a standard, the Generalized Inter-ORB Protocol (GIOP). There are several versions of the protocol, and NonStop CORBA supports GIOP 1.0, 1.1, and 1.2. One variation of GIOP is the Internet Inter-ORB Protocol (IIOP). IIOP uses GIOP messages over the TCP/IP transport mechanism. The OMG defines a set of data formatting rules, called CDR (Common Data Representation), which is tailored to the data types supported in the CORBA Interface Definition Language (IDL). Using the CDR data formatting rules, the specification also defines a set of message types that support all of the ORB semantics. Together, the CDR formatting rules and the message formats constitute an abstract protocol called GIOP. GIOP messages can be sent over virtually any data transport protocol, such as TCP/IP, the TS/MP Pathsend interface, the NonStop server file system, and many others. To ensure out-of-the-box interoperability between ORB products, the IIOP specification requires that ORBs send GIOP messages over TCP/IP connections because TCP/IP is the standard connection-oriented transport protocol for the Internet. To put it very simply, GIOP + TCP/IP = IIOP. Objects publish their identities and locations in the form of object references. CORBA specifications dictate a common format for object references exchanged over IIOP, called the IOR (Interoperable Object Reference) format. An IOR contains one or more profiles. Each profile describes how a client object can contact and send requests to the object using a particular protocol. For interoperability between ORBs provided by different vendors, an IOR should contain an IIOP profile to ensure that wherever that reference goes, any CORBA ORB can locate the object and send requests to it. The IIOP profile contains the Internet address of the object s server and a key value used by the server to find the specific object described by the reference. Object references can be converted into character strings, which can be published arbitrarily, like URLs, in messages, files, databases, directories, and so on. Any CORBA application can convert the string into an IOR and use it to locate and invoke the object. Alternatively, the IOR can be obtained from the Naming Service. When a client program built with one ORB vendor s product needs to talk to an object in a server built with another ORB vendor s product, the client program opens a TCP/IP connection to the server and sends one or more IIOP requests to the server. The ORB component linked into the server locates or activates the object specified in the request and invokes the appropriate method on the object. The fact that the object is not built with the same ORB product is invisible to the client. CORBA/IIOP is platform-independent. CORBA ORBs interoperate without regard to vendor origin, making CORBA/IIOP the truly ideal solution for the Internet. NonStop CORBA can use three transport protocols when communicating between objects. All three use GIOP and each can be represented as a profile within an IOR. These three protocols are: IIOP, the standard messaging protocol utilizing TCP/IP, used for all remote messages to platforms other than NonStop server platforms. GIOP over TS/MP inter-orb protocol implementation. This protocol is used when accessing objects whose server is controlled by TS/MP.

15 GIOP over Guardian file system inter-orb protocol Implementation). This protocol is used when client objects wish to communicate with objects whose server is either running as a stand-alone process or as stateful objects managed by TS/MP. The tools for configuring these protocols are described later in this manual. GIOP Over TS/MP Protocol HP strongly recommends configuring your production servers with the GIOP over TS/MP protocol, because this protocol leverages the features of process management, process persistence, load balancing, and scalability. (This protocol is also known as GCFIOP, or Guardian Context-Free Protocol.) A server that supports TS/MP can be configured as either a single process or as a group of processes within a server pool. In either case, client messages and server replies are sent using TS/MP interprocess communication when both client and server reside on the NonStop platform. GIOP over TS/MP is a protocol internal to NonStop CORBA. All inter-orb communication can use this NonStop CORBA protocol, however, all heterogeneous ORB communication must still take place through the TCP/IP protocol used by IIOP. GIOP Over Guardian File System Protocol A server that supports only the file-system protocol can be configured either as a stand-alone process or as a named process managed by TS/MP. The NonStop CORBA system manages client access to file-system servers using interprocess communication (IPC). Clients must use the file-system protocol to talk to a server that supports only this protocol. IIOP over SSL The NonStop CORBA SSLIOP (Secure Sockets Layer Inter-ORB Protocol) provides the Internet Inter-ORB Protocol (IIOP) over the SSL secure connection mechanism. SSLIOP provides transport security for NonStop CORBA objects. The SSL layer operates between the IIOP and TCP layers, providing a transparent secure channel. NonStop CORBA objects can interoperate with other vendor's IIOP/SSL implementations. SSLIOP provides a set of scripts that allow you to create a private Certificate Authority, and create certificates for testing. You can also obtain certificates from an outside Certificate Authority. What certificates and which Certificate Authority to use for production depends upon the security policies of your organization or business. Administrators can configure NonStop CORBA to use IIOP/SSL with existing applications that are not aware of security features. Alternatively, programmers can gain programmatic control of the IIOP/SSL configuration and operation by creating or modifying applications to make them aware of security features. Note that IIOP/SSL is an optional feature set that must be installed and configured on your system before it can be used. Portable Interceptors NonStop CORBA supports the Portable Interceptors API as defined in the OMG CORBA core specification, except as noted in the NonStop CORBA Programmer's Reference. The Portable Interceptors API allows applications to intercept the flow of a request-reply sequence. Request interceptors enable ORB services to transfer context information between clients and servers. IOR interceptors establish tagged components in the profiles within an IOR. Client/Server Process A NonStop CORBA server is any process that resides on the same NonStop system or Expand network. An object contained by a NonStop system CORBA server can act as a client, a server, or both. CORBA objects execute from within a server process. Two types of CORBA servers are available on the NonStop system, stand-alone CORBA servers or CORBA servers within the TS/MP environment. A stand-alone CORBA server process does not have any load balancing or automatic scale applied to it during execution. In contrast, a CORBA server running within the TS/MP environment allows the CORBA server to be contained within a server pool. In a server pool objects may be stateless and/or stateful. These CORBA servers are automatically fault-tolerant (as defined by the TS/MP application script). The objects within these CORBA servers may also balance loads. Note that stateless objects are automatically load balanced upon each method request. Stateful objects are load balanced upon each instantiation and then each method request is directed to the same server-pool process for execution. NonStop CORBA Remote Services The NonStop CORBA remote services are services that enable high-volume, high-performance access from other systems. Figure 1 6 shows the architecture of the remote services. Figure 1.2. NonStop CORBA Remote Services

16 Client System Remote clients, or network clients, are application processes that reside on other systems and other vendors ORBs. They act as CORBA clients to CORBA application objects or any of the COS services that reside on the NonStop system. They normally interact with those services through the Location Service Daemon (LSD) and the Comm servers. The interaction between the remote clients and the remote services is always done through the standard IIOP protocol. Configuration Database Execution information required by NonStop CORBA is maintained in a database called the configuration database. This database is built during the product installation and configuration process. Configuration information stored in the configuration database is dynamic. Changes to the data are made by: Users of the NonStop Distributed Component Console Users of the configuration management tool (cfgmgt) NonStop CORBA servers All NonStop CORBA programs use the configuration database to obtain values that govern the behavior of the program. For example, the

17 configuration database identifies the transport protocols used by the server. Some CORBA servers place information into the configuration database. For example, the naming service stores the root naming context object reference into the configuration database. The configuration database enables NonStop CORBA to use implementation-specific data. Since these data are obtained from a database instead of appearing in the server code, the servers can be portable. Comm Server The Comm server is a component of NonStop CORBA that provides connectivity to applications for network clients. These clients obtain the benefits of the Comm server without any special programming. CORBA requests and responses may be routed through the Comm server based on information contained in the interoperable object reference used by the client. The Comm server provides two benefits: It acts as a gateway to facilitate communication between network clients and application servers on the NonStop CORBA system. It acts as a network resource concentrator thus enabling construction of large-scale servers. As a gateway, the Comm server enables network clients to interact with NonStop CORBA servers. In some cases the servers do not directly support the IIOP protocol that network clients must use. This is true in the case of servers hosting stateless objects. Each request to a stateless object may be routed to a different server-pool process. Here the Comm server is used to interact with the TS/MP facility to perform the routing. Without the Comm server, network clients could not make use of these stateless objects. As a network resource concentrator, the Comm Server makes efficient use of network resources. For large-scale systems having many CORBA clients and servers, the Comm server manages network communications between network clients and NonStop CORBA servers, thus reducing the demand for TCP/IP ports (a potentially scarce resource on the system). A single Comm Server process may handle many network clients simultaneously; however, depending on needs of your system, multiple Comm servers can be configured. Using multiple Comm Servers allows larger volumes of traffic to be handled because the load is spread across multiple processors. Parallel Library TCP/IP Another way to increase capacity and fault tolerance is to configure the IIOP connectivity components of your system (Comm Server, LSD, ILSD, and BSD processes) to use Parallel Library TCP/IP. With this configuration, multiple Comm Server processes running in a pool can share the same port. A round-robin filter distributes the incoming connections among the Comm Server pool. When configured this way the Comm Server pool appears as a single IP host to the outside world. Figure 1 7 shows the original way of configuring TCP/IP in a NonStop system. Note: There is one Comm Server per port, limiting throughput on that port. There is a TCP/IP process between the ServerNet adapter and a Comm Server, requiring a message system hop. Figure 1.3. Original TCP/IP Each Fast Ethernet ServerNet Adapter (FESA) corresponds to a TCP/IP port. By comparison, configuring the IIOP connectivity components of your system to use Parallel Library TCP/IP allows publishing a single port for up to 16 Comm Server processes. Message system hops are reduced by moving execution of TCP data-path functions from the TCP/IP process into the user process (Comm Server in this case), referencing the Parallel Library TCP/IP SRL. Figure 1.4. Parallel Library TCP/IP

18 With this configuration the single port can be serviced by up to 16 actual processes with only one Comm Server pool and only one configuration database entry. Similarly, up to 16 Location Service Daemon (LSD) processes can be configured to avoid a potential LSD bottleneck. The GIOP over TS/MP protocol can be used in combination with Parallel Library TCP/IP to provide two different dimensions of scalability. As shown in Figure 1 8, Parallel Library TCP/IP provides scalability by allowing multiple processes to listen at one port. If you configure multiple ports (using multiple ServerNet adapters), TS/MP provides scalability by allowing you to configure one process per port. For more information about the architecture and features of Parallel Library TCP/IP, see the TCP/IP (Parallel Library) Configuration and Management Manual, particularly the section on configuring Parallel Library TCP/IP for complex and heavy-use environments. Location Service Daemon (LSD) The Location Service Daemon (LSD) is a component that often acts as a first point of contact for network clients. The LSD uses NonStop CORBA configuration information along with information in the request to redirect the request to the correct server or Comm server. Following the initial interaction with the LSD, subsequent client requests should not require interactions with the LSD. When the LSD determines that a Comm server should handle the request, the LSD selects an appropriate Comm server. Selection of a Comm server is made based on several factors including: The IP address of the client making the request The number of available Comm servers The current load being handled by each Comm server Configuration decisions made by the system administrator Once an association is made between a particular client IP address and a Comm server, the same association is used for subsequent requests from the same client. Interoperable Location Service Daemon (ILSD) The Interoperable Location Service Daemon (ILSD) is a component of the Interoperable Naming Service. The ILSD services requests for name resolution for names in the Uniform Resource Locator (URL) format. When the ILSD receives such a request, it returns a forwarding reply containing the object reference of the named object. For requests involving names that use the corbaloc style of URL, the ILSD returns the object reference based on locally stored object references. For requests involving names that use the corbaname style of URLs, the ILSD enlists support of the Interoperable Naming Service to produce the object reference that is returned to the caller. Bootstrap Daemon (BSD) The Bootstrap Daemon (BSD) is a component of the Interoperable Naming Service. The BSD is needed for interoperability with other ORBs using the Bootstrap protocol. The BSD protocol provides operations for resolving an initial object reference and for listing the supported initial reference ids. Interoperable client ORBs send a request to an initialization agent. The agent replies to the client ORB with the requested information. The IDL interface provides two operations, a get(), which accepts an ObjectId and a list(), which accepts no arguments. The IDL interface for the two operations is as follows:

19 module CORBA{ interface InitialReferences { Object get(in ObjectID id); ObjectIdList list(); }; }; Any client ORB must obtain the initial root naming context on an arbitrary host in an interoperable fashion. Using a file system relies on the presence of a shared file system and an agreed location. These specific and often platform dependent mechanisms prevent all clients from obtaining the root naming context in a portable and interoperable way. The BSD uses a standard interoperable protocol to bootstrap to the initial root naming context on any arbitrary host. ORBs that implement BSD issue Bootstrap GIOP request messages: CORBA::ORB::resolve_initial_reference(ObjectId) This operation is equal to a "get" and results in a request with an object key equal to "INIT". CORBA::ORB::ObjectIdList CORBA::ORB::list_initial_services() This operation is equal to "list" and results in a request with an object key equal to "INIT". The BSD plays the server role in the bootstrap protocol as it is an fd socket listener. The BSD configuration includes an IP address and a URL directory. The default is $NSD_ROOT/urls. The BSD replies to the list request with a string sequence listing the files in the URL directory. It replies to resolve the request with an object reference. The parameter identifies a file in the URL directory and the BSD reads the file into a string and passes the string to CORBA::ORB::string_to_object. The client role of the bootstrap protocol is not supported by NonStop CORBA. Activating the BSD Bootstrap Protocol The BSD's IP address is passed to the client by setting: 'org.omg.corba.orbinitialhost' to the BSD's host address 'org.omg.corba.orbinitialport' to the BSD's port number An example of a client start script instructs JDK 1.3 on an NT system to use the Bootstrap protocol to communicate with the BSD in a NonStop CORBA subsystem running on a specific host: java -Dorg.omg.CORBA.ORBInitialHost= <change_me> -Dorg.omg.CORBA.ORBInitialPort=4506 Test %1 %2 %3 Where, change_me is a dot-separated IPv4 address like or colon-separated IPv6 address like fe80::a00:8eff:fe06:d093 and 4506 is the BSD port number. NonStop CORBA does not use the BSD default port of 900, but uses a port dynamically assigned during installation. The port number can be altered using the Console or the cfgmgt utility to modify the bsd1@orb entity. Interface Repository Database The Interface Repository (IR) is a set of files that contain definitions of object interfaces hosted on your NonStop CORBA application servers. Information in the IR can be used by clients that access servers using the Dynamic Invocation Interface (DII), as defined by the CORBA specifications. You access the IR database programmatically through the interface defined in the CORBA Interface Repository specification. The Common Object Services NonStop CORBA implements the following CORBA services: Naming Service Event Service Transaction Service Naming Service The NonStop CORBA Naming Service implements the Naming Service based on the OMG Naming Service Specification 1.2, with one minor exception as noted in the NonStop CORBA Programmer's Reference. The Naming Service provides a repository for the names and locations of NonStop CORBA application objects. The Naming Service enables developers to register object names at runtime. In the Naming Service database, naming contexts and their associated object references are organized into a hierarchical namespace. Client applications can then use the Naming Service to discover the names and object references for objects they wish to use. The NonStop CORBA Naming Service is fully and transparently integrated with TS/MP and the Transaction Management Facility (TMF), making the Naming Service fully scalable, reliable, and performance-oriented. The Naming Service consists of the Naming Server executable program (deployed as a server pool) and its respective Naming Service database along with the Interoperable Naming Service Daemon (ILSD). The Naming Server maintains the Naming Service database using key-sequenced Enscribe files. Applications can bind names to objects and retrieve them by using the CORBA-defined object interface to the Naming Service.

20 Event Service The NonStop CORBA Event Service is implemented based on the OMG CORBA Event Service specification version 1.1. The Event Service provides asynchronous communication among CORBA objects. The Event Service allows supplier objects to communicate through an event channel, notifying any number of consumer objects when events they subscribe to take place. The Event Service consists of the Event Service executable, which is also deployed as a server pool. Applications interact with this server pool by using the CORBA-defined object interfaces to the Event Service. Transaction Service The NonStop CORBA Transaction Service (OTS) is implemented based on the OMG Transaction Service specification version 1.1. The Object Transaction Service is an object-oriented, transaction processing system. Using HP s proven large-scale transactional management and services infrastructure, application providers can deliver reliable objects that fully support the ACID properties of a transaction service. NonStop CORBA provides two language bindings: OTS (which is used when developing in C++) and JTS (Java Transaction Service). JTS is the Java API used when developing objects with Java. This Transaction Service extends the CORBA model by supporting transaction processing between distributed objects, providing for interoperable transaction processing within existing CORBA systems. Figure 1.5. Transaction Service Components Figure 1 9 shows the software components that implement the Transaction Service in NonStop CORBA. The following components are provided by NonStop CORBA: OTS and JTS client stubs NSotsTM process NSotsXID process These components are referred to collectively as NSOTS (when used with C++ applications) and NSJTS (when used with Java applications). The OTS client stub implements the OMG Transaction Service API for C++ programs. The JTS client stub implements the Java Transaction Service (JTS) API for Java programs. Both stubs have special capabilities beyond those of client stubs generated by the IDL compiler. To use these stubs, you link them with your applications just as you link the stubs generated from your application's IDL code. NSotsTM is a process that collaborates with the Transaction Management Facility (TMF) on the NonStop system to manage transactions. TMF and NSotsTM work together as equals, alternating in superior and subordinate roles as needed. You can configure the NSotsTM process to run as a TS/MP server pool. NSotsXID is a singleton process used to broker transaction identifiers (XIDs) when NSotsTM runs as a TS/MP server pool with multiple processes. When creating transactional applications using JTS/OTS, concentrate your efforts on the clients and servers that invoke and handle requests made within the scope of a transaction; the low-level details of the transaction processing are transparently handled for you by the NonStop CORBA OTS Transaction Manager (OTSTM). A Look at Transactions The word transaction connotes a unit of work in which a client can modify one or more objects. At the end of the transaction process, a decision is made whether to commit or rollback the changes made in effect of the transaction. This is a group decision based on the outcome of each individual piece of work associated with the transaction. Committing a transaction means that all of the changes made during the transaction will be made durable. Rolling back, or aborting, a transaction means that none of the changes made during the transaction will be made durable and the state of the objects involved in the transaction will remain unchanged from the state they were in before the transaction was started. A rollback may also occur if certain failures are encountered during the processing of the transaction. Transaction processing gives you the ability to process multiple changes to the data that an application accesses.

21 The ACID Properties of a Transaction A transaction is a unit of work that behaves in accordance with the ACID properties that have become synonymous with transaction processing. In transactions that are distributed across one or more systems, a Transaction Manager is normally relied upon to carry out the low-level details involved in orchestrating a transaction. By assuring the ACID properties outlined below, a Transaction Manager can ensure that its transaction processing is secure and reliable: Atomic A transaction is atomic when it either commits all individual changes made by the transaction or rolls back any changes the transaction produced. A transaction must be an all or nothing procedure. Consistent A transaction must take the system from one consistent state to another. In doing so, the transaction must preserve the invariant properties of the system. Isolated The unit of work performed by a transaction must be hidden from other entities accessing the system while the work is being carried out. The intermediate states of a transaction must not be visible to other transactions or to other objects that access the data on which the transaction is working. Transactions appear to execute serially, even if they are performed concurrently. Durable No effects of a completed, committed transaction can be lost; they must all be persistently stored. With this, a transaction is a series of operations that takes a system from one consistent state to another. Transactional Objects The OMG Transactional Service Specification defines a transactional object as an object whose behavior is affected by being invoked within the scope of a transaction. A transaction object typically contains or indirectly references persistent data that can be modified by a request made within the scope of a transaction. Transactional Clients A client can make requests of any mix of transactional and nontransactional objects. However, if a client application makes any request within the scope of a transaction, it is termed a transactional client. Transaction Manager (OTSTM) The OTSTM is a server-pool process that is installed and configured to run under the PATHMON process that runs the other system processes. The OTSTM assures that the ACID properties of a transaction are kept in check throughout the processing of the transaction. The OTSTM works in concert with NonStop TM/MP, orchestrating the two-phase commit protocol, which insures the integrity of all transaction data during the termination of the transaction. The OTSTM depends heavily on the interfaces defined in the transaction service. Two-Phase Commit Process The OTSTM uses a two-phase commit process to ensure that each transaction maintains the ACID characteristics associated with transaction processing. To understand the workings of a two-phase commit, it is helpful to first understand the processing of a rollback operation. When a transaction terminates, all participants associated with the transaction must either commit or roll back. If, while processing a transaction, a transaction participant finds that it must roll back the transaction, it issues a rollback. The OTSTM handles this request by invoking the roll back call on each transaction participant associated with that transaction thread. The process used to commit a transaction is similar to the roll back process described above. However, committing a transaction involves two steps, or phases. The first phase occurs when all objects invoked to do work in the scope of the transaction return from their calls. At this point, all transaction participants establish a state from which they can either make any transaction modifications invisible or undo their share of the transaction work. When all outstanding transaction operations return, the client invokes a commit() operation. To handle this request, the OTSTM issues a prepare() operation to all participants associated with the transaction. The prepare() essentially polls each participant, asking if they are ready to commit the transaction by making all transaction changes durable. Here, each participant in the transaction must vote on whether the overall outcome of the transaction is to commit or rollback. Based on the responses received from the first phase, the OTSTM begins the second phase of the commit protocol. If all transaction participants voted to commit the transaction, the OTSTM terminates the transaction by calling the commit() operation on each participant. It is after this call that all changes made in effect of the transaction are made durable. However, if even a single transaction participant indicates (votes) that it cannot commit, the OTSTM will invoke the rollback() operation on all participants associated with the transaction. This effectively aborts any modifications that may have been made in effect of the transaction processing. Checked Behavior The OTSTM also implements a checked transaction behavior, which provides an extra level of transaction integrity. Checked behavior ensures that all client transactional operations have been successfully completed before the transaction can be committed. With the checked behavior, the Transaction service can guarantee that a commit will not succeed unless all of the transactional objects involved in the transaction have

22 completed processing their transactional requests. Resource Managers The Transaction Service Specification describes a Resource Manager, which is the database(s) involved with a transaction. NonStop CORBA supports two resource managers, NonStop SQL/MP and Enscribe. These resource managers are responsible for making durable any changes required by a transaction commit. In addition to these resource managers, the OTSTM uses NonStop TM/MP to interface with these resource managers. Note: NonStop TM/MP is completely covered in the NonStop TM/MP documentation set. For detailed information on how to administer NonStop TM/MP and how to recover from catastrophic events, refer to these documents. Transaction Context In a client/server scenario, a transaction typically begins when a client invokes a begin() operation. The client's request is marshalled to a server object that is capable of handling the request. After all requests associated with a transaction have returned, the client (also known as the transaction originator) can issue a request to complete the transaction. When a client initially begins the transaction, a transaction context is generated that is associated with the client thread. The transaction context is the transaction information associated with a specific thread. The objects participating in the transaction use the transaction thread throughout the lifespan of the transaction. Propagating the Transaction Context Transaction propagation refers to the act of associating the transaction context of a client with the operations performed by a transactional object. In the Transaction Service Specification, two types of propagation are defined: implicit and explicit. Currently, only implicit propagation is supported. With implicit propagation, the transaction context associated with a request is automatically propagated by the ORB with the request; the server handling the request shares the transaction context of the client. In this case, the transaction context is transmitted implicitly without direct intervention from the client. This is different than explicit propagation, where the client directly passes the transaction context as a parameter to the object server. Controlling Transactions The OMG Transaction Service Specification details two models with which you can control transactions: Indirect context management uses the Current object to associate the transaction context with the application thread of control. Direct context management uses the Control object along with other objects to control transactions. NonStop CORBA applications typically use indirect context management, where the client uses the CosTransactions::Current() interface to create and control transactions. However, an application can also directly manage the transaction by accessing the Control object (for example, to resume a suspended transaction). While NonStop CORBA also supports direct context management to make requests with respect to a particular transaction context, this method of transaction control is strongly discouraged. Application Portability For an application to be portable across different CORBA-compliant Transaction Service implementations, the application should implement a flat transaction model. In the flat model, the Transaction Service must treat all transactions as top-level transactions. They cannot have child (or nested) transactions. By making use of a flat transaction model, NonStop CORBA server objects can participate in transactions invoked from a foreign OTS. Note: The Transaction Service Specification includes references to both flat transactions and nested transaction, with nested transaction being optional functionality. For the greatest range of portability, OTS supports only flat transactions. About This Guide Chapter 2. System Management

23 Chapter 2. System Management Chapter 2. System Management NSDAdminServer and NSDEnvironServer Purpose of NSDAdminServer and NSDEnvironServer Starting and Stopping NSDAdminServer Starting NSDEnvironServer Configuration Data Used by NSDAdminServer and NSDEnvironServer What You Need to Know NSDAdminServer and NSDEnvironServer Purpose of NSDAdminServer and NSDEnvironServer Starting and Stopping NSDAdminServer Starting NSDEnvironServer Configuration Data Used by NSDAdminServer and NSDEnvironServer Purpose of NSDAdminServer and NSDEnvironServer The NonStop Distributed Component Console (called the Console) requires support services from the systems it manages. The processes that provide these support services are the NSDAdminServer and the NSDEnvironServer. For any given NonStop Kernel system, there is a single NSDAdminServer process with which the Console communicates. There are one or more NSDEnvironServer processes, depending on the number of security domains that have been configured. The NSDAdminServer process is the initial point of contact for a Console that needs to manage components on the system. This process provides information and services that are independent of any particular security domain, for example: Information about the available security domains Logon authentication for a security domain System configuration information such as the available CPUs, disks, and TCP processes Management of security domains The NSDEnvironServer process provides services for a particular security domain. Generally, the NSDEnvironServer processes are created by the NSDAdminServer on demand. The NSDEnvironServer process provides information and services specific to a security domain, for example: Starting and stopping processes Providing status-update information about processes Retrieving and storing configuration information Management of business domains Starting and Stopping NSDAdminServer The NonStop CORBA installer starts the NSDAdminServer process so that the Console can use it. The installer runs runadmin, which starts an admin server that is not a TS/MP server class. If the NSDAdminServer process is stopped, you must restart it. You can start the NSDAdminServer either as a stand-alone OSS process or as an OSS process running under PATHMON control. Starting NSDAdminServer as a Stand-Alone Process Stopping the Stand-Alone Process Starting NSDAdminServer as a PATHMON Process Stopping the PATHMON Process Starting NSDAdminServer as a Stand-Alone Process To run the NSDAdminServer as a stand-alone OSS process: 1. Set the required environment variables (see The env.sh Source File). 2. At the OSS command prompt, give the command runadmin, with or without one or more of these options:

24 -a admin-db specifies an administration database other than that defined by the NSDOM_ADMIN_DB environment variable. -t causes the NSDAdminServer to generate additional output. This output is typically used for troubleshooting. An NSDAdminServer process named $ZDAS starts running. Stopping the Stand-Alone Process To stop the NSDAdminServer that was started using the command runadmin, give the following command from the OSS command prompt: gtacl -c 'stop $ZDAS' Starting NSDAdminServer as a PATHMON Process To run the NSDAdminServer under PATHMON control: 1. Set the required environment variables (see The env.sh Source File). 2. At the OSS command prompt, give the command adminstart, with or without one or more of these options: -a admin-db specifies an administration database other than that defined by the NSDOM_ADMIN_DB environment variable. -t causes the NSDAdminServer to generate additional output. This output is typically used for troubleshooting. -v causes adminstart to generate output as it executes. This output can be useful for troubleshooting. An NSDAdminServer process named $ZDAS starts running under a PATHMON process named $xdapm where x is defined by the MY_PREFIX environment variable. Stopping the PATHMON Process To stop the NSDAdminServer that was started using the command adminstart, give the following command at the OSS command prompt: adminstop The NSDAdminServer sends its output to the admin.log file in the log directory. Starting NSDEnvironServer Generally you need not start an NSDEnvironServer process, because it is started on demand by the NSDAdminServer. If you do need to start one: 1. Set the required environment variables (see The env.sh Source File). 2. At the OSS command prompt, give the command runenviron, with or without one or more of these options: -a admin-db specifies an administration database other than that defined by the NSDOM_ADMIN_DB environment variable. -c file-name specifies a file containing configurations to manage. -d domain-name specifies the name of the domain managed by the server. A corresponding profile ES_domain must exist in the administration configuration database. By default the logon name is used as the domain name. -n directs the server not to scan for configurations to manage. -t causes the NSDAdminServer to generate additional output. This output is typically used for troubleshooting. An NSDEnvironServer process starts running with a system-assigned process name. Configuration Data Used by NSDAdminServer and NSDEnvironServer

25 NSDAdminServer and NSDEnvironServer use an administration configuration database to store operational data. The location of this database is given by the environment variable NSDOM_ADMIN_DB. This variable is defined by the installer and appears in the env.sh script (see The env.sh Source File). Generally you do not need to change the contents of the administration configuration database, because the servers manage the data automatically. If necessary, you can use the cfgmgt tool to view the contents of the administration configuration database (see Appendix B, cfgmgt Command Reference). What You Need to Know To manage the NonStop CORBA runtime environment, you should be familiar with the following topics: Procedures and considerations for managing TS/MP subsystems Procedures and considerations for managing NonStop TCP/IP, Parallel TCP/IP, LAN, QIO, and X25AM Syntax and use of the following tools and utilities: NonStop Distributed Component Console PATHCOM interface Subsystem Control Facility (SCF) Configuration Management Tool (cfgmgt) NonStop CORBA error log facility NonStop CORBA trace facility Ptrace utility Event Management Service (EMS) Format and semantics of the following files: OSS.profile file Initialization file (default.db) PATHCOM configuration file (nsdstart) SCF configuration file TCP/IP HOSTS file or DNS boot and domain data files The following manuals provide information about managing NonStop systems: Document Title NonStop TS/MP Pathsend and Server Programming Manual NonStop TS/MP System Management Manual Pathway/iTS Management Programming Manual Pathway/iTS System Management Manual TACL Reference Manual Introduction to NonStop SQL/MP NonStop DCE Application Programming Guide Open System Services Programmer's Guide Open System Services Management and Operation Guide Open System Services Porting Guide Open System Services User's Guide Open System Services Shell & Utilities Reference Manual SCF Reference Manual for G-Series Releases TCP/IP Configuration and Management Manual TCP/IP (Parallel Library) Configuration and Management Manual TCP/IP (Parallel Library) Migration Guide LAN Configuration and Management Manual QIO Configuration and Management Manual X25AM Configuration and Management Manual HP NonStop Transaction Management Facility (TMF) Operations and Recovery Guide HP NonStop Transaction Management Facility (TMF) Reference Manual Notes TS/MP server pools, PATHCOM interface TACL command reference NonStop database products DCE pthreads Open System Services shell and utilities, libraries and system calls Configuring communications subsystems Managing TMF databases, TMFCOM

26 EMS Manual Event Management Service (EMS) Analyzer Manual EMS configuration and management Chapter 1. NonStop CORBA Architecture Chapter 3. Configuration and Management Using the Console

27 Chapter 3. Configuration and Management Using the Console Chapter 3. Configuration and Management Using the Console Overview of the Console Connecting to Host System Managing Business and Security Domains Security Domains Business Domains Monitoring the Servers Server Status Indicators Detailed Server Status Display Status Information for NSDAdminServer and NSDEnvironServer Controlling the Servers Starting the Servers Stopping the Server Stopping Managing the Servers Viewing and Configuring Server Properties General Properties Naming Service Properties Event Service Properties Object Transaction Service (OTS) Properties Object Transaction Service XID (OTSXID) Properties Location Service Daemon (LSD) Properties Bootstrap Daemon (BSD) Properties Comm Server Properties Viewing and Configuring Comm Server Mappings Displaying the Comm Server Map Adding a Comm Server Mapping Removing a Comm Server Mapping Managing Naming Service Data Displaying the Naming Service Hierarchy Adding a Naming Context Renaming a Naming Context or Name Removing a Naming Context or Name Viewing an Object Reference Saving an Object Reference Refreshing the Display Using the Console to Troubleshoot the Servers Load Balancing Overview of the Console You can configure and manage NonStop CORBA by using a combination of the following tools: HP NonStop Kernel Open System Services (OSS) commands Guardian commands (for example, pathcom) cfgmgt

28 commands Shell scripts provided with the product The NonStop Distributed Component Console This chapter describes how to configure and manage NonStop CORBA by using the Console. The Console is a GUI-based tool that allows you to manage: One or more host systems on which applications are running The server processes that implement NonStop Services for CORBA Using the Console, you can: Connect to one or more host systems Manage security domains, business domains, and domain servers Monitor the servers using status indicators and detailed server status displays Control (start and stop) the servers View and configure server properties View and configure Comm Server mappings Manage Naming Service data using the Naming Administrator Troubleshoot the servers The Console is recommended for configuring and managing the NonStop Services for CORBA. However, you can use the command line tools and shell scripts to configure and manage the system if you prefer them (see Configuration and Management Using Commands). Note that it is easier to make mistakes with the tools and scripts than with the Console. The data that the Console manages the configuration data is stored in the configuration database on the host system. With caution, you can use the cfgmgt tool to view and modify the configuration data. The NSDAdminServer and the NSDEnvironServer use the Subsystem Programmatic Interface (SPI) to PATHMON to configure, start, stop, and monitor the status of servers. Connecting to Host System After launching the Console, you connect to a host system that you want to manage and select a security domain and one or more business domains. After you have connected to a host system, you can define additional security domains and business domains as required by your site. 1. Select Manage System from the Admin menu or click Manage a system on the tool bar. 2. The System Selection dialog appears. Type either the name or the IP address of the host system, then click OK. If you enter a name, it must be one that can be found by a host name lookup (usually performed by the Domain Name Service). The Security Domain Selection dialog appears. 3. Select a security domain, then click OK. The Security Domain Authentication dialog appears. 4. Log on to the security domain by typing the user name and password for the security domain you selected. Click OK. The Business Domain Selection dialog appears. 5. Select a business domain, then click OK. (To select multiple business domains, press the Shift key while selecting.) The main Console window lists the business domains under the host system and security domain. Now you can either add more domains or start the servers. Managing Business and Security Domains Security Domains Business Domains Security Domains A security domain contains the process and configuration data that are manageable under a user name and password. An initial security domain is created when you install the product. If you choose to do so, you can define additional security domains for a host system. A security domain is composed of one or more business domains. Adding a New Security Domain Removing a Security Domain Adding a New Security Domain Add additional security domains if, for example, you want to partition your system. Each security domain corresponds to a Guardian user logon. The processes created under a given security domain have access rights corresponding to the user ID that controls the security domain.

29 You can add a security domain either while you are selecting a host system to manage or when you are already managing a host system (for step-by-step instructions, see the Console's online help). In either case, you must provide the following information: Field Information Required Security Meaningful name for the security domain. Can contain alphabetic, numeric, and underscore characters. domain name Logon name User ID for the security domain. This is the Guardian logon name for the host system. Logon Password for the Guardian logon name. password TCP process Name of the TCP process that is managing the selected host address. One TCP process can manage multiple host addresses. TCP processes can be spread across CPUs for load balancing. If the Use Parallel Library TCP/IP check box is checked, specify a TCP process that is enabled for Parallel Library TCP/IP. Search for business domains to manage Leave checked to search the host system for business domains owned by the logon name. Once found, you can select one or more business domains to manage under the new security domain. (Depending on the system, the search process can take some time.) Uncheck this option if you plan to manage business domains that are not yet defined. Removing a Security Domain To remove a security domain, select the name of the security domain in the tree, then choose menu item View Domains Security. The dialog that appears allows you to choose security domains and remove them if desired. Business Domains A business domain contains a collection of related business application processes and configuration data. Multiple business domains can be defined for one security domain. An initial business domain is created when you install the product. Adding a New Business Domain Removing a Business Domain Renaming a Business Domain Adding a New Business Domain Add additional business domains if, for example, you want to partition your security domain. Each business domain has its own set of NonStop Services for CORBA processes. Separate business domains can ensure that processes running under one business domain do not interfere with processes running under a different business domain. You can add a business domain either while you are selecting a host system to manage or when you are already managing a host system (for step-by-step instructions, see the Console's online help). In either case, you must specify its General Properties. See Viewing and Configuring Server Properties (especially the subtopic General Properties). Removing a Business Domain To remove a business domain, select the name of the security domain in the tree, then choose menu item View Domains Business. The dialog that appears allows you to choose business domains and remove them if desired.

30 Renaming a Business Domain To rename a business domain: 1. Select the NonStop Services for CORBA item in the tree that corresponds to the business domain you want to rename. 2. View the properties for the business domain. 3. Alter the domain name field as desired, then click OK. Monitoring the Servers After connecting to the host system, the Console retrieves information about the configuration and status of each server. You can monitor the status of each server by looking at: Server Status Indicators Detailed Server Status Display Status Information for NSDAdminServer and NSDEnvironServer The server status indicators and the detailed server status display are updated in real time as changes occur. Server Status Indicators To display the server status indicators: 1. Select NonStop Services for CORBA 2. Display the list of servers by expanding NonStop Services for CORBA Server Status Indicators Indicator Meaning Server is running. At least one server component is not running normally. Server is stopped. In the following display, all of the servers are running:

31 Detailed Server Status Display To display detailed server status information, do one of the following: Right-click NonStop Services for CORBA and select Server Status from the pull-down menu. Select NonStop Services for CORBA and select Server Status from the View menu. The following information is displayed about each server: Information Description Class Type of server pool. Possibilities are: LSD (Location Service Daemon) ILSD (Interoperable Location Service Daemon) BSD (Bootstrap Daemon) CS (Comm Server) NS (Naming Service) ES (Event Service) IRD (Interface Repository Database) OTSTM (Object Transaction Service Transaction Monitor) OTSXID (Object Transaction Service XID) Process State Information Names of the processes in the server pool Running, Stopped, Pending, or Suspended Displays information about errors, including the time the error occurred and error type. Possibilities are: Config (configuration error) Server (operational error) Error Description For example:

32 Status Information for NSDAdminServer and NSDEnvironServer You can view the status information for the NSDAdminServer and NSDEnvironServer. You might want to view it to get operational information about the servers. You can also enable and disable tracing. To view the status information: 1. Highlight the name of a security domain in the tree (a security domain name appears along with the name of the system at the highest level in the tree). 2. Select Server Status from the View Menu. A dialog appears showing status information for the servers. To enable or disable tracing for a server, select the Enable tracing check box, then click OK. Here is an example:

33 Controlling the Servers After connecting to a host system and selecting security and business domains, you can: Start the servers Stop the servers Stop managing the servers Start or stop the servers in the following situations: You have connected to a host system and selected security and business domains, and the server status indicators show that one or more servers is either stopped or is not running normally. Stop all of the servers and restart them. You have changed any of the server properties. You must stop and restart the servers to have the changes take effect. Starting the Servers Do one of the following: Right-click NonStop Services for CORBA and select Start from the pull-down menu. Select NonStop Services for CORBA and select Control>Start from the Admin menu. Select NonStop Services for CORBA and click Start running on the tool bar. The status indicator showing that the server is running ( ) should appear on the left-hand side of each server. Stopping the Server Do one of the following: Right-click NonStop Services for CORBA and select Stop from the pull-down menu. Select NonStop Services for CORBA and select Control>Stop from the Admin menu. Select NonStop Services for CORBA and click Stop running on the tool bar. The status indicator showing that the server is stopped ( ) should appear on the left-hand side of each server. Stopping Managing the Servers If you are managing multiple host systems from a Console window and you no longer need to manage a particular set of servers, you can remove that set of servers from the Console window. The servers are still defined and might be running or not, but they no longer appear in the Console window. 1. Select NonStop Services for CORBA under a particular business domain.

34 2. Select Stop Managing from the Admin menu. The servers for that set of NonStop Services for CORBA are removed from the Console window. If you want to resume managing the servers you removed: 1. Exit the Console 2. Restart the Console 3. Reconnect to the host system Viewing and Configuring Server Properties The servers have default values defined for their properties. You do not have to change these values; however, server configuration properties determine how well the client request load is balanced, so you might want to tailor server configuration properties to meet your needs. Note: Any changes to the server properties require you to stop and restart the servers. To display General properties and then view properties for a specific server: 1. Do one of the following: Right-click NonStop Services for CORBA and select Properties from the pull-down menu. Select NonStop Services for CORBA and click View properties on the tool bar or select Properties from the View menu. 2. Click the tab for the server properties you want to view. To display properties for a specific server without reviewing General properties: 1. Select NonStop Services for CORBA. 2. Display the list of servers by expanding NonStop Services for CORBA. 3. Do one of the following: Right-click the server and select Properties from the pull-down menu. Select the server and click View properties on the tool bar or select Properties from the View menu. The window in which you can view and change server configuration properties looks like this:

35 The following tabs are available: General Properties Naming Service Properties Event Service Properties Object Transaction Service (OTS) Properties Object Transaction Service XID (OTSXID) Properties Location Service Daemon (LSD) Properties Bootstrap Daemon (BSD) Properties Comm Server Properties Interface Repository Database (IRD) Properties Interoperable Location Service Daemon (ILSD) Properties General Properties Required Configuration Advanced Configuration Required Configuration Property Domain name OSS Product Directory Description Meaningful name for the business domain. Can contain alphabetic, numeric, and underscore characters. Name of the directory under which the product was installed, for example: /usr/tandem/nsdoms. A browse button is available for navigating to the directory.

36 OSS Data Directory Guardian Product Directory Database Directory Environment Prefix Advanced Configuration Property Name Primary CPU Backup CPU I/O Size Use default Use Parallel Library TCP/IP for Comm Servers Directory under which configuration and log files are stored for a business domain. Each business domain requires a separate location for its data files. For one business domain, this location can be the same as the OSS Product Directory. A browse button is available for navigating to the directory. Name of the Guardian $volume.subvolume in which the product was installed. Name of the Guardian $volume.subvolume under which the configuration database and Naming Service database are stored for a particular business domain. Each business domain requires a separate location for its data files. For one of your business domains only, this location can be the same as that specified in the Guardian Product Directory field. One letter attached to the front of some process names. Each business domain has its own set of NonStop Services for CORBA. The environment prefix distinguishes process names among various sets of NonStop Services for CORBA. Description The PATHMON process for the NonStop Services for CORBA for a particular business domain. The default name consists of "$" and the environment prefix character, followed by NDM. The process name can be altered when the business domain is initially defined. Number of the CPU designated as the primary CPU for the PATHMON process. Number of the CPU designated as the backup CPU for the PATHMON process. Size, in bytes, of buffers used for sending messages. The default size should accommodate most messages. Large messages are automatically segmented into multiple buffers as needed. You might want to specify a larger I/O size if most messages are large. Making the I/O size larger reduces the amount of message segmentation and makes sending messages more efficient, although it does so by using additional memory. To specify an I/O size other than the default of 4096, uncheck Use default and type another value. If checked, the default value of 4096 is used for I/O Size. To specify an I/O size other than the default, uncheck the box and change the value of the I/O Size field. If checked, enables the use of Parallel Library TCP/IP. Note that after this is checked you must also complete the Comm Server properties panel correctly to finish configuring Parallel Library TCP/IP. Always review the Comm Server properties panel after changing this check box. Naming Service Properties Basic Configuration Server Configuration Options Troubleshooting Options Basic Configuration Property Description Database file Object reference file Name and location of the Naming Service database file. You cannot change the file name or location. The file is displayed in case you want to back it up or perform some other administrative action. Note that the file name is based on the database directory specified on the General Properties dialog. Location of the object reference file for the Naming Service. Changing the location of this file is not recommended. Server Configuration Options Property Description Maximum Maximum number of copies of a server process that can run in a server pool at the same time. The range of values is 0

37 Server through Static Servers Process Name Number of static servers, which are processes that are started automatically when the TS/MP environment starts. (Dynamic servers are started as needed by the PATHMON process.) The range of values is 0 through The value must not exceed the value of the Maximum servers field. For better performance, the number of static servers should be close to or equal to the value for Maximum servers. Name of the server process. If you do not choose a name, the system assigns one when the process starts. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Create delay Delete delay Max links Link depth Send timeout Log file Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Length of time in microseconds requests are queued while a LINKMON process waits for a server (static or dynamic) to become available. When this time is exceeded, the PATHMON process creates a dynamic server to process requests. The maximum time is 18 hours. Length of time in microseconds the PATHMON process waits before deleting unused dynamic server processes. The maximum time is 18 hours. Maximum number of links that a server process in a server pool can have to all LINKMON processes on the host system. For example, if the Link depth field is set to 10 and there are 3 CPUs in the host system, set the Max links field to 30 to avoid queueing requests at the server process. While a server process is processing a request, the maximum number of queued requests is the value of the Max links field minus 1. The range of Max links values is 0 through Number of concurrent links allowed from a LINKMON process to a particular server process in a server pool. The range of values is 1 through 255. Set the value of Link depth to be less than or equal to the value of Max links. If Max links is 0, use the default value of 1 for Link depth. Length of time in microseconds the LINKMON process waits for a server process I/O operation to complete. The maximum time is 18 hours. Name of the file to which server process output is written. Event Service Properties Basic Configuration Server Configuration Options Troubleshooting Options Basic Configuration Property Host address Port number TCP process Initially create Register channel or factory in Naming Service Name Write object Description IP address of the host system on which the server is listening. The host systems available in the drop-down list are those managed by the selected TCP process. Port number on the host system to which the server is listening. The port number cannot be used by any other process on the host system. Name of the TCP process that is managing the selected host address. One TCP process can manage multiple host addresses. TCP processes can be spread across CPUs for load balancing. If the "Use Parallel Library TCP/IP" check box is checked, specify a TCP process that is enabled for Parallel Library TCP/IP. Select either Event Channel Factory (to initially create an event channel factory) or Event Channel (to initially create a single event channel). Event Channel Factory is the typical choice. Recommended: Leave this box checked so that applications can find the event channel or event factory in the Naming Service. Name that is associated with the event channel or event channel factory in the Naming Service. Recommended: Leave this box checked. Applications without access to object references in the Naming Service

38 reference to a file File name Server Configuration Options Property might need to get the object reference from a file. Name of the object reference file. Description Process Name of the server process. If you do not choose a name, the system assigns one when the process starts. name Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Log file name Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Name of the file to which server process output is written. Object Transaction Service (OTS) Properties Server Configuration Options Troubleshooting Options Server Configuration Options Property Maximum servers Static servers Process name Description Maximum number of copies of a server process that can run in a server pool at the same time. The range of values is 0 through Number of static servers, which are processes that are started automatically when the TS/MP environment starts. (Dynamic servers are started as needed by the PATHMON process.) The range of values is 0 through The value must not exceed the value of the Maximum servers field. For OTS, it is recommended to configure the Static servers field to be equal to Maximum servers, because using dynamic servers can lead to aborted transactions under some circumstances. Setting the number of static servers close to or equal to the value for Maximum servers also enhances performance. Name of the server process. If you do not choose a name, the system assigns one when the process starts. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Create delay Delete delay Max links Link depth Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Length of time in microseconds requests are queued while a LINKMON process waits for a server (static or dynamic) to become available. When this time period is exceeded, the PATHMON process creates a dynamic server to process requests. The maximum time is 18 hours. Length of time in microseconds the PATHMON process waits before deleting unused dynamic server processes. The maximum time is 18 hours. Maximum number of links that a server process in a server pool can have to all LINKMON processes on the host system. For example, if the Link depth field is set to 10 and there are 3 CPUs in the host system, set the Max links field to 30 to avoid queueing requests at the server process. While a server process is processing a request, the maximum number of queued requests is the value of the Max links field minus 1. The range of Max links values is 0 through Number of concurrent links allowed from a LINKMON process to a particular server process in a server pool. The range of values is 1 through 255. Set the value of Link depth to be less than or equal to the value of Max links. If Max links is 0, use the default value of 1 for Link depth.

39 Send timeout Log file name Length of time in microseconds the LINKMON process waits for a server process I/O operation to complete. The maximum time is 18 hours. Name of the file to which server process output is written. Object Transaction Service XID (OTSXID) Properties When transaction context is inherited from one process to another, an imported transaction branch is created. A transaction branch is represented by a new TMF transaction identifier called the XID. The root XID and any branch XIDs are not recognized by TMF or SQL as representing the same transaction. This means that if a process such as an application starts a transaction and makes multiple invocations on server processes, multiple XIDs can be created resulting in SQL errors or blocking. To solve this problem, NSotsTM includes an XID Broker function. Server Configuration Options Troubleshooting Options Server Configuration Options Property Maximum servers Static servers Process name Description Maximum number of copies of a server process that can run in a server pool at the same time. The range of values is 0 through 1. Number of static servers, which are processes that are started automatically when the TS/MP environment starts. (Dynamic servers are started as needed by the PATHMON process.) The range of values is 0 through The value must not exceed the value of the Maximum servers field. For better performance, the number of static servers should be close to or equal to the value for Maximum servers. Name of the server process. If you do not choose a name, the system assigns one when the process starts. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Log file name Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Name of the file to which server process output is written. Location Service Daemon (LSD) Properties The Location Service Daemon (LSD) acts as a well-known entry point for initial external client connections. It also maps external clients to Comm Servers. When a remote client initially invokes a method on a server object, the request goes to the LSD. The LSD checks the Comm Server Map to determine if the remote client's host system is mapped to a Comm Server. If the remote client's host system has an entry in the Comm Server Map, the LSD returns the address information for that Comm Server. If the remote client's host system is not registered in the Comm Server Map, the LSD determines whether the request should be handled by a direct TCP server or by a Comm Server. If the request should be handled by a TCP server and one is available, the LSD returns the TCP/IP address of that server. If no TCP server is available or the request should be handled by a Comm Server, the LSD assigns the least busy Comm Server to the client. The address information sent to the client by the LSD includes the TCP/IP address and port number of the least busy Comm Server. If Parallel TCP/IP is enabled, the TCP/IP address sent is the next Comm Server available in round-robin fashion. The Comm Server then routes requests and responses between the client and the application server. Note that the interactions among the servers described here are performed on behalf of the client by the Object Request Broker infrastructure. These interactions are transparent to the client program, and no client programming is required. Basic Configuration Server Configuration Options Troubleshooting Options Basic Configuration Property Description Host address Port IP address of the host system on which the server is listening. The host systems available in the drop-down list are those managed by the selected TCP process. Port number on the host system to which the server is listening. The port number cannot be used by any other process on

40 number TCP process Use Parallel Library TCP/IP the host system. At installation, this port number is set to a value based on the port number you specify for TCP/IP. If you have more than one copy of NonStop CORBA installed on a NonStop server, each copy must have a different port number. Name of the TCP process that is managing the selected host address. One TCP process can manage multiple host addresses. TCP processes can be spread across CPUs for load balancing. If the "Use Parallel Library TCP/IP" check box is checked, you must specify a TCP process that is enabled for Parallel Library TCP/IP. If checked, enables the LSD to use Parallel Library TCP/IP. Server Configuration Options Property Maximum servers Static servers Process name Description If the check box for Use Parallel Library TCP/IP is not checked, this field is set to one. If it is checked, you may specify the number of servers. If the check box for Use Parallel Library TCP/IP is not checked, this field is set to one. If it is checked, this field is set to match the number of Maximum Servers you specify. Or if you enter a number of Static Servers, the Maximum Servers field will be set to match what you enter here. Name of the server process. If you do not choose a name, the system assigns one when the process starts. If the check box for Use Parallel Library TCP/IP is checked you must enter at least as many names as the number of servers that have been specified. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. If the check box for Use Parallel Library TCP/IP is checked you must enter at least as many CPU numbers as the number of servers that have been specified. This field cannot contain duplicate CPU numbers. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Log file name Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Name of the file to which server process output is written. Bootstrap Daemon (BSD) Properties The Bootstrap Daemon is needed for interoperability with other ORBS using the Bootstrap protocol. It provides operations for resolving an initial object reference and for listing the supported initial reference ids. Basic Configuration Server Configuration Troubleshooting Options Basic Configuration Property Description Host address Port number TCP process Use Parallel Library IP address of the host system on which the server is listening. The host systems available in the drop-down list are those managed by the selected TCP process. Port number on the host system to which the server is listening. The port number cannot be used by any other process on the host system. At installation, this port number is set to a value based on the port number you specify for TCP/IP. If you have more than one copy of NonStop CORBA installed on a NonStop server, each copy must have a different port number. Name of the TCP process that is managing the selected host address. One TCP process can manage multiple host addresses. TCP processes can be spread across CPUs for load balancing. If the "Use Parallel Library TCP/IP" check box is checked, you must specify a TCP process that is enabled for Parallel Library TCP/IP. If checked, enables the BSD to use Parallel Library TCP/IP.

41 TCP/IP Server Configuration Options Property Maximum servers Static servers Process name Description If the check box for Use Parallel Library TCP/IP is not checked, this field is set to one. If it is checked, you may specify the number of servers. If the check box for Use Parallel Library TCP/IP is not checked, this field is set to one. If it is checked, this field is set to match the number of Maximum Servers you specify. Or if you enter a number of Static Servers, the Maximum Servers field will be set to match what you enter here. Name of the server process. If you do not choose a name, the system assigns one when the process starts. If the check box for Use Parallel Library TCP/IP is checked you must enter at least as many names as the number of servers that have been specified. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. If the check box for Use Parallel Library TCP/IP is checked you must enter at least as many CPU numbers as the number of servers that have been specified. This field cannot contain duplicate CPU numbers. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Log file name Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Name of the file to which server process output is written. Comm Server Properties The Comm Server is a router that allows remote clients to communicate with application servers on a host system. A remote client uses a single port to access any number of application servers. (In some other products, a separate port is required for each application to which a client connects.) Allowing connections to multiple application servers through one port reduces network resource consumption. Network resource use can be important when a large number of remote clients request server resources. A single Comm Server can handle requests from many remote clients. As requests increase, you can configure additional Comm Servers to balance the load. If Parallel Library TCP/IP has been enabled on the General tab, the fields available for specifying Comm Server properties differ. The properties for each option are listed separately in the following tables. Comm Server Properties for Original TCP/IP Number of Comm Servers Basic Configuration Server Configuration Options Troubleshooting Options Number of Comm Servers Property Number of Comm Servers Basic Server Configuration Property Comm server Dedicated servers Host address Port Description Description As the client requests increase, you can increase the number of Comm Servers to handle the additional load. Number of the Comm Server for which you want to view or configure properties. If checked, the specified Comm Server is designated as a dedicated server. When the Location Service Daemon (LSD) maps external clients to Comm Servers and is looking for the least busy Comm Server, the LSD excludes any dedicated Comm Servers from the search. A dedicated Comm Server is used only if it has a manually entered Comm Server mapping. IP address of the host system on which the server is listening. The host systems available in the drop-down list are those managed by the selected TCP process. Port number on the host system to which the server is listening. The port number cannot be used by any other process on

42 number TCP process Process name the host system. At installation, the user is prompted to select a value for this port number. Name of the TCP process that is managing the selected host address. One TCP process can manage multiple host addresses. TCP processes can be spread across CPUs for load balancing. Name of the Comm Server process. The system assigns process names for Comm Servers, and the names start with the environment prefix. You cannot change Comm Server process names. Processor Number of the CPU on which the Comm Server is running. You can specify another CPU to balance loads across CPUs. To improve performance, specify the CPU in which the TCP process is running (then data from the TCP process to the Comm Server does not have to travel across CPUs). Server Configuration Options Property Description Process priority Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. Autorestart attempts Log file name Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Name of the file to which server process output is written. Comm Server Properties for Parallel Library TCP/IP Property Configuration for Group Basic Server Configuration Server Configuration Options Troubleshooting Options Description Configuration for Group If more than one group is specified, this drop-down menu allows you to choose which group to view. Number of Groups The number of groups specified. The usual number is one. Basic Server Configuration Property Host address Port number TCP process Dedicated server Description IP address of the host system on which the server is listening. Port number on the host system to which all Comm Server processes in the group are listening. The port number cannot be used by any other process on the host system. At installation, the user is prompted to select a value for this number. Name of the TCP process that is used by the Comm Server group. This process must be enabled for Parallel Library TCP/IP. If checked, the specified Comm Server is designated as a dedicated server. The Location Service Daemon (LSD) skips dedicated Comm Servers when creating external client mappings. A dedicated Comm Server is used only if it has a manually entered Comm Server mapping. Server Configuration Options Property Maximum servers Static servers Process name Description The number of Comm Server processes in the group. The number of maximum servers and static servers must be the same. The number of static Comm Server processes in the group. The number of static servers and maximum servers must be the same. The names of the Comm Server processes in the group. The names must be specified. The number of names specified must equal the number of maximum servers. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. You must enter at least as many CPU numbers as the number of servers that have been specified. This field cannot contain duplicate CPU numbers. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is

43 Log file name Name of the file to which server process output is written. Interface Repository Database (IRD) Properties The Interface Repository Database is a set of files that contain definitions of object interfaces hosted on the application servers. Information in the Interface Repository can be used by clients that access servers using the Dynamic Invocation Interface. You can access the object definitions in the Interface Repository Database programmatically through the CORBA Interface Repository methods. Basic Configuration Server Configuration Options Troubleshooting Options Basic Configuration Property Description Repository name The repository name is displayed for information purposes only; you cannot change it. Repository file Name of the file containing the Interface Repository Database. Object reference file Location of the object reference file for the service. Changing the location of this file is not recommended. Server Configurations Property Maximum servers Static servers Process name Description Maximum number of copies of a server process that can run in a server pool at the same time. The range of values is 0 through Number of static servers, which are processes that are started automatically when the TS/MP environment starts. (Dynamic servers are started as needed by the PATHMON process.) The range of values is 0 through The value must not exceed the value of the Maximum servers field. For better performance, the number of static servers should be close to or equal to the value for Maximum servers. Name of the server process. If you do not choose a name, the system assigns one when the process starts. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Create delay Delete delay Max links Link depth Send timeout Log file name Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Length of time in microseconds requests are queued while a LINKMON process waits for a server (static or dynamic) to become available. When this time period is exceeded, the PATHMON process creates a dynamic server to process requests. The maximum time is 18 hours. Length of time in microseconds the PATHMON process waits before deleting unused dynamic server processes. The maximum time is 18 hours. Maximum number of links that a server process in a server pool can have to all LINKMON processes on the host system. For example, if the Link depth field is set to 10 and there are 3 CPUs in the host system, set the Max links field to 30 to avoid queueing requests at the server process. While a server process is processing a request, the maximum number of queued requests is the value of the Max links field minus 1. The range of Max links values is 0 through Number of concurrent links allowed from a LINKMON process to a particular server process in a server pool. The range of values is 1 through 255. Set the value of Link depth to be less than or equal to the value of Max links. If Max links is 0, use the default value of 1 for Link depth. Length of time in microseconds the LINKMON process waits for a server process I/O operation to complete. The maximum time is 18 hours. Name of the file to which server process output is written. Interoperable Location Service Daemon (ILSD) Properties The Interoperable Location Service Daemon (ILSD) is an interoperable Naming Service forwarding agent. The ILSD receives requests targeted at corbaloc and corbaname URLs. The ILSD uses the object key to determine how to forward requests.

44 Basic Configuration Server Configuration Options Troubleshooting Options Basic Configuration Property Description Host address Port number TCP process URL directory Use Parallel Library TCP/IP IP address of the host system on which the server is listening. The host systems available in the drop-down list are those managed by the selected TCP process. Port number on the host system to which the server is listening. The port number cannot be used by any other process on the host system. At installation, this port number is set to a value based on the port number you specify for TCP/IP. If you have more than one copy of NonStop CORBA installed on a NonStop server, each copy must have a different port number. Name of the TCP process that is managing the selected host address. One TCP process can manage multiple host addresses. TCP processes can be spread across CPUs for load balancing. If the check box for Use Parallel Library TCP/IP is checked, you must specify a TCP process that is enabled for Parallel Library TCP/IP. Location where the Interoperable Location Service Daemon expects to find object reference files. If checked, enables the ILSD to use Parallel Library TCP/IP. Server Configuration Options Property Maximum servers Static servers Process name Description If the check box for Use Parallel Library TCP/IP is not checked, this field is set to one. If it is checked, you may specify the number of servers. If the check box for Use Parallel Library TCP/IP is not checked, this field is set to one. If it is checked, this field is set to match the number of Maximum Servers you specify. Or if you enter a number of Static Servers, the Maximum Servers field will be set to match what you enter here. Name of the server process. If you do not choose a name, the system assigns one when the process starts. If the check box for Use Parallel Library TCP/IP is checked you must enter at least as many names as the number of servers that have been specified. Processors List of CPUs in which server processes can run. Separate the CPU numbers with commas; for example, 1,2,5. If you do not specify a list of CPUs, the system runs server processes in any available CPU. Specifying certain CPUs requires the system to use only the CPUs in the list. If the check box for Use Parallel Library TCP/IP is checked you must enter at least as many CPU numbers as the number of servers that have been specified. This field cannot contain duplicate CPU numbers. Process Priority at which the server process is run. The range of values is 1 through 199, the highest priority being 199. priority Autorestart attempts Create delay Delete delay Max links Link depth Number of attempts to restart the server process, in the event of its abnormal termination. The maximum number is Length of time in microseconds requests are queued while a LINKMON process waits for a server (static or dynamic) to become available. When this time period is exceeded, the PATHMON process creates a dynamic server to process requests. The maximum time is 18 hours. Length of time in microseconds the PATHMON process waits before deleting unused dynamic server processes. The maximum time is 18 hours. Maximum number of links that a server process in a server pool can have to all LINKMON processes on the host system. For example, if the Link depth field is set to 10 and there are 3 CPUs in the host system, set the Max links field to 30 to avoid queueing requests at the server process. While a server process is processing a request, the maximum number of queued requests is the value of the Max links field minus 1. The range of Max links values is 0 through Number of concurrent links allowed from a LINKMON process to a particular server process in a server pool. The range of values is 1 through 255. Set the value of Link depth to be less than or equal to the value of Max links. If Max links is 0, use the default value of 1 for Link depth.

45 Send timeout Log file name Length of time in microseconds the LINKMON process waits for a server process I/O operation to complete. The maximum time is 18 hours. Name of the file to which server process output is written. Viewing and Configuring Comm Server Mappings The Comm Server is a router that allows remote clients to communicate with application servers on a host system. The Comm Server Map shows the associations between remote client host systems and Comm Servers. The Location Service Daemon (LSD) uses the Comm Server Map to route incoming requests from remote clients. The LSD looks up the remote client's host system in the Comm Server Map. If the remote client's host system has an entry in the Comm Server Map, the LSD returns the address information for that Comm Server. If there is no Comm Server Map entry, the LSD creates one and adds it to the Comm Server Map. You can add and remove Comm Server mappings to balance the load of client requests among Comm Servers. Displaying the Comm Server Map Adding a Comm Server Mapping Removing a Comm Server Mapping Displaying the Comm Server Map Do either of the following: Right-click NonStop Services for CORBA and select Comm Server Map from the pull-down menu. Select NonStop Services for CORBA and select Map from the View menu. The following information is displayed about each server: Information Description Source address IP address of the remote client host system sending a request through a Comm Server Comm Server Process name of the Comm Server that handles requests from the remote client host system Last accessed Date and time the Comm Server was last accessed For example: Adding a Comm Server Mapping 1. Display the Comm Server Map. 2. Click Add. The Add Comm Server Map Entry dialog appears. 3. Type the IP address of the remote host system sending the request through a Comm Server in the Source Address field. 4. Select a Comm Server to service client requests from the drop-down list. 5. Click OK. The new Comm Server mapping is shown in the Comm Server Map. 6. To exit the Comm Server Map display and save your changes, click OK. To exit without saving changes, click Cancel.

46 Removing a Comm Server Mapping 1. Display the Comm Server Map. 2. Select a map entry to remove, then click Remove. The entry is no longer displayed in the Comm Server Map. 3. To exit the Comm Server Map display and save your changes, click OK. 4. To exit without saving changes, click Cancel. Managing Naming Service Data The Naming Service Administrator allows you to manage the data in the Naming Service Displaying the Naming Service Hierarchy Adding a Naming Context Renaming a Naming Context or Name Removing a Naming Context or Name Viewing an Object Reference Saving an Object Reference Refreshing the Display. Displaying the Naming Service Hierarchy To display Naming Service data using the Naming Administrator, do one of the following: Right-click NonStop Services for CORBA and select Name Admin from the pull-down menu. Select NonStop Services for CORBA and select Name Admin from the View menu. Display the list of servers by expanding NonStop Services for CORBA and do one of the following: Right-click Naming Service and select Name Admin from the pull-down menu. Select Naming Service and select Name Admin from the View menu. The Naming Service Administrator display appears. For example:

47 Left Pane The Naming Service hierarchy is displayed in a tree structure. Initially, the Root Naming context is expanded to show the naming contexts and names at the root level of the hierarchy. Naming contexts are indicated by a folder icon and can be expanded to show the names contained in them. Naming contexts and names consist of two attributes separated by a period: id.kind. For example, NSDOMES.EventChannelFactory. id is required and is the identifier, or name ID; in this example NSDOMES kind is optional and contains a descriptive string; in this example EventChannelFactory Note that id can consist of multiple subparts separated by periods. kind always follows the last period. Right Pane When the Naming Service Administrator display first appears, this pane is blank. When you select to view an object reference for a name, also called an interoperable object reference (IOR), the object reference fields are shown in the right pane. These fields identify the object and permit requests to be routed to the object. The object reference fields include the object type ID, object key, and addressing information. Adding a Naming Context 1. Display the Naming Service hierarchy. 2. Do one of the following: Right-click an existing naming context and select New Context from the pull-down menu. Select an existing naming context and select New Context from the Action menu. 3. When the Input dialog appears, type the new naming context in id.kind format. The identifier attribute (id) is required. The kind attribute, a descriptive string for the type of naming context, is optional and, if present, is separated from the id by a period. Example: NSDOMES.EventChannelFactory. 4. Click OK. The new name appears in the Naming Service hierarchy. Renaming a Naming Context or Name 1. Display the Naming Service hierarchy. 2. Do one of the following: Right-click an existing naming context and select Rename from the pull-down menu. Select an existing naming context and select Rename from the Action menu. 3. When the Input dialog appears, type the new naming context in id.kind format. The identifier attribute (id) is required. The kind attribute, a descriptive string for the type of naming context, is optional and, if present, is separated from the id by a period. Example: NSDOMES.EventChannelFactory. 4. Click OK. The new name appears in the Naming Service hierarchy Removing a Naming Context or Name 1. Display the Naming Service hierarchy. 2. Do one of the following: Right-click the naming context or name and select Remove from the pull-down menu. Select the naming context or name and select Remove from the Action menu. 3. Click Yes when prompted to confirm the removal. The name no longer appears in the Naming Service hierarchy. Viewing an Object Reference View an object reference for a name to verify or examine its properties, such as its name binding, type ID, or available protocols for containing the object. 1. Display the Naming Service hierarchy. 2. Do one of the following: Double-click the name in the hierarchy. Right-click the name in the hierarchy and select View IOR from the pull-down menu. Select the name in the hierarchy and select View IOR from the Action menu. The object reference fields are shown in the right pane of the Naming Service Administrator display. Saving an Object Reference

48 Save (download) an object reference if, for example, you want to make an object reference available to an application that does not want to obtain the object reference from the Naming Service. 1. Display the Naming Service hierarchy. 2. Do one of the following: Right-click the name in the hierarchy and select Save IOR from the pull-down menu. Select the name in the hierarchy and select Save IOR from the Action menu. 3. Indicate the file in which you want to save the IOR by typing its path name or by using the browse feature to navigate to the directory. Click OK. The file is saved in the location specified. Refreshing the Display Refresh the Naming Service Administrator display when a running program has updated the Naming Service since you first displayed the Naming Service hierarchy. To refresh the display, do one of the following: Right-click a naming context select Refresh from the pull-down menu. Select a naming context and select Refresh from the Action menu. The display is refreshed for the naming context you selected and all naming contexts subordinate to it. Using the Console to Troubleshoot the Servers If one or more servers are not started: 1. Display detailed status for the servers. 2. If the status display does not reveal the cause of the problem, stop and restart the servers. 3. If one or more servers are still not started, review the log files. If a server is not functioning as expected: 1. Review the log file. 2. If the log file does not reveal the cause of the problem, enable the Tracing option on the server properties dialog. 3. If tracing does not reveal the cause of the problem, enable Debug for the server on the server properties dialog. Troubleshooting Options Property Description Tracing Enable tracing when you are troubleshooting a problem with the server. When enabled, the tracing option writes information to the log file. The recommended procedure for tracing is to enable Basic tracing first, which might give you enough information to solve the problem. If you need more information, enable Detailed tracing for additional detail. (The NonStop CORBA Programmer's Guide for C++ and the NonStop CORBA Programmer's Guide for Java provide more information about how to trace individual environment variables.) Disable tracing when you are finished troubleshooting. Enable debug When enabled, the server process starts in the Inspect interactive symbolic debugger. Use Inspect to communicate with the process and debug it. Disable debugging when you are finished troubleshooting. For some problems it is also worthwhile to check the EMS log file. See the EMS Manual for information about EMS log files. Load Balancing The Console allows you to configure server properties to balance the client request load by: Changing the priority at which a server process is running (see Viewing and Configuring Server Properties) Changing the CPU in which a server process is running (see Viewing and Configuring Server Properties) Changing the number of Comm Servers configured for the host system (see Viewing and Configuring Server Properties) Configuring additional Comm Servers to balance the load (see Viewing and Configuring Server Properties) Adding and removing Comm Server mappings to balance the load of client requests among Comm Servers (see Viewing and Configuring Comm Server Mappings) Selecting a TCP process from a list of those available when you define a security domain (see Adding a New Security Domain) or when you configure server properties (see Viewing and Configuring Server Properties) If Parallel Library TCP/IP is configured, Comm Servers are chosen on a round-robin basis rather than on load (see Comm Server

49 Properties and Parallel Library TCP/IP. Chapter 2. System Management Chapter 4. Configuration and Management Using Commands

50 Chapter 4. Configuration and Management Using Commands Chapter 4. Configuration and Management Using Commands Configuration Setting Environment Variables (env.sh file) Customizing the env.sh file Configuration Database Configuration Management Tool (cfgmgt) Managing NonStop CORBA Processes Starting and Stopping NonStop Services for CORBA How the nsdstart Script Works Troubleshooting: Problems Starting NonStop Services for CORBA Differences Between Using Scripts and Using the PATHCOM Interface Customizing the nsdstart Script Configuring NonStop CORBA to Use Parallel Library TCP/IP Configuring the BSD, LSD and ILSD for Parallel Library TCP/IP Configuring a Comm Server for Parallel Library TCP/IP Configuring Additional Parallel Library TCP/IP Comm Servers Using the PATHCOM Interface to Maintain TS/MP Processes Using the PATHCOM Interface Starting a PATHMON Process Restarting a Previously Defined TS/MP Configuration Monitoring Status Displaying Configuration Information Displaying Status Information Displaying Statistical Information Modifying Global Parameters Based on Changing Requirements Reconfiguring Server Pools Adding a Server Pool Modifying Running Server Pools Altering a Server Pool Managing the Distributed Object Environment The Distributed Object Environment NonStop CORBA Configuration Management NonStop CORBA Performance Tuning NonStop CORBA Troubleshooting You can configure and manage NonStop CORBA by using a combination of the following tools: HP NonStop Kernel Open System Services (OSS) commands Guardian commands (for example, pathcom) cfgmgt commands Shell scripts provided with the product The NonStop Distributed Component Console This chapter describes how to configure and manage NonStop CORBA by using the command-line interface and scripts Configuration

51 This section assumes that you have successfully completed installing your NonStop CORBA system as described in Installing NonStop CORBA. The installation process gives you a fully configured system. Later you may wish to make modifications to your configuration. The information in this section shows you how to perform these configuration tasks. Most of the commands described in this section are used in the Open System Services (OSS) environment. You should be familiar with OSS before attempting any of the configuration tasks described in this section. To modify the scripts described here you need to use a text editor such as the vi editor. For more information about using OSS commands and the vi editor see the Open System Services User's Guide. You should also be familiar with the Guardian environment and file system before starting to configure and manage your system. See the Guardian User's Guide for information about working in the Guardian environment. Setting Environment Variables (env.sh file) Each NonStop CORBA setup uses a unique set of environment variables. The file env.sh, found in the etc product subdirectory, sets up the NonStop CORBA environment variables that are used by the other NonStop CORBA scripts and by some programs. After you install the NonStop CORBA product, the settings in env.sh are correct for your installation. When using the various NonStop CORBA programs and shell scripts, you must ensure that the correct environment variables are in effect. To do so, issue the following OSS shell command from your NonStop CORBA base directory:. etc/env.sh This command reads env.sh file and sets the environment variables in your current OSS shell session. Alternatively, you can put the command in the OSS.profile script. This script is executed each time you enter OSS. For example, assuming you have installed the NonStop CORBA in the directory /usr/tandem/nsdoms, you could put the following line in your.profile file:. /usr/tandem/nsdoms/etc/env.sh Customizing the env.sh file You might want to customize the env.sh file to reflect a special NonStop CORBA setup. For example, if you wanted to move the NonStop CORBA files from one Guardian subvolume to another, you need to make a change to the NSD_DIR and NSD_SUBVOL environment variables in env.sh. Use a text editor to modify env.sh. After editing the file, you must execute the script (as described in Setting Environment Variables) in order for the new settings to take effect. Note: While you can freely move your application files, you should not move NonStop CORBA files to a different Guardian subvolume or OSS directory if you use the Distributed Systems Management/Software Configuration Manager (DSM/SCM) to manage your NonStop CORBA Installation. DSM/SCM will not be aware of the location of any files you move. The following table gives a brief description of each environment variable set in the env.sh script. The table also shows the default script settings. Variable Default Setting* Description NSD_ROOT /usr/tandem/nsdoms Sets the root OSS directory for your NonStop CORBA installation. MY_ROOT $NSD_ROOT Sets up a custom NSD_ROOT variable to allow for multiple custom installations. By default, the value is the same as NSD_ROOT. NSD_DIR NSD_SUBVOL /G/SYSTEM/ZORBSDK or /G/SYSTEM/ZORBRTK "\$SYSTEM.ZORBSDK" or "\$SYSTEM.ZORBRTK" Specifies the NonStop CORBA Guardian volume and subvolume for NonStop Kernel files; must be expressed in OSS directory format. Same as NSD_DIR, but expressed in NonStop Kernel (Guardian) format (a backslash before the dollar sign and a double-quoted directory location). MY_SUBVOL $NSD_SUBVOL Sets a custom NSD_SUBVOL, which allows for multiple installations. By default, the value is the same as NSD_SUBVOL. NSD_SRL_SUBVOL $NSD_SUBVOL Specifies in NonStop Kernel format the Guardian volume and subvolume where the NonStop CORBA for Java shared runtime libraries (DLLs) reside. By default, the value is the same as NSD_SUBVOL. NSD_SRL_DIR $NSD_DIR Specifies in OSS format the Guardian volume and subvolume where the NonStop CORBA for Java DLL resides. By default, the value is the same as NSD_DIR. _RLD_LIB_PATH File NSDDLL in the NSD_SRL_SUBVOL A DEFINE that specifies the location of the NonStop CORBA DLL. NSDOM CFG DBM $MY SUBVOL.NSDCFGDB

52 NSDOM_ADMIN_DB Set by installer Specifies the NonStop Kernel filename for the configuration database. Specifies the NonStop Kernel filename for the administration database. MY_PREFIX Z Specifies a unique prefix letter for the NonStop CORBA process names. Use this environment variable prevent process name conflicts if you have multiple NonStop CORBA installations on a single system. You must set this as an uppercase letter. MY_COLLECTOR '$0' Specifies the EMS collector process used by the NonStop CORBA processes. The name is defined in NonStop Kernel format. Modify this line if you want to use a different collector other than the system default of $0. COMP_ROOT Specifies the root location where your tools, such as c89, are located. Modify this line if the tools you want to use are in a location other than the system default. JAVA_HOME /usr/tandem/java Sets path for NSJ. Modify this line if your installation of NSJ is in a different location than this default. JREHOME $JAVA_HOME/jre Specifies Java Runtime Environment home (for NSJ 7) NSD_BOOTCP CLASSPATH PATH $JREHOME/lib/tandemvm.jar: $JREHOME/lib/rt.jar Specifies the boot classpath needed by TS/MP scripts (for NSJ 7) CLASSPATH=.:$NSD_ROOT/lib/jorb.jar: Sets up the CLASSPATH for the Java ORB. $NSD_ROOT/lib/jts.jar $PATH:$NSD_ROOT/bin: Adds the NonStop CORBA for Java bin and lib directories to $NSD_ROOT/bin/unsupported: $COMP_ROOT/usr/lib: $JAVA_HOME/bin the current path. * The default setting might be different, because it depends on the options you selected when you ran the NonStop CORBA installer program. Configuration Database The configuration information for the NonStop CORBA system is stored in the configuration database file. The installer program creates this file during product installation. The file location is defined by environment variable NSDOM_CFG_DBM. The file is an Enscribe file that is stored in the Guardian file space. The configuration database is used by various NonStop CORBA programs, by the NonStop Distributed Component Console, and by the configuration management tool (cfgmgt). Each of these programs can read information from the database as well as alter its contents. The data are structured as a collection of entities or records. Each of these has a unique name that always conforms to the following syntax: profile@attribute An example of such a name is NS@ORB. Each entity consists of a series of keys and associated values. Both keys and values consist of strings of characters. You must enclose white space in double quotation marks. Within a particular entity each key must be unique. While there are some standard entities in the configuration database, the specific entities in a particular database depend upon the installation. Appendix A lists some standard entities and their contents. There are no constraints on what entities can appear in the configuration database nor on what keys and values comprise an entity; however, many of the NonStop CORBA system components and the NonStop Distributed Component Console expect certain entities to be present. Be careful not to make changes that could adversely affect system operation. Whenever possible, use the Console to manipulate the contents of the configuration database, because the console helps to ensure data consistency. Configuration Management Tool (cfgmgt) describes the use of the configuration management tool that can be used to view and alter the configuration database when necessary. Most work is accomplished using only a few of the available commands, which are described in the following subsections. For a complete list of the available commands, see Appendix B. Configuration Management Tool (cfgmgt) Starting cfgmgt Displaying All Entities Displaying a Particular Entity Changing an Entity Adding an Entity Deleting an Entity Exiting cfgmgt Starting cfgmgt

53 Start cfgmgt from the OSS command prompt by using this command: cfgmgt [-r] cfgmgt is command-based. The command prompt identifies the current configuration database. The -r option opens the database for read only. If you have difficulty starting cfgmgt, verify that your environment variable settings are correct. In particular: The environment variable PATH must be set to refer to the bin directory of your product installation. The environment variable NSDOM_CFG_DBM must be set to refer to the configuration database you wish to manipulate. Displaying All Entities To display all the entities in the configuration database, use this command: entities Each entity has a name of the form profile@attribute, where profile and attribute are any strings. When you have the list of available entities, you can use other commands to manipulate them. Displaying a Particular Entity To display the entity whose name is entity-name, use this command: entity entity-name This command displays the entity's keys and their values. For example, the command entity NS@ORB could result in the output: use_comm_server true tcp_server true fs_server true tsmp_server true server_class NS Changing an Entity To change an entity, type the entity name followed by an open brace. This command causes subsequent lines to modify the entity. Each line contains a single key and its associated value. A closing brace terminates data entry. When an input line contains a key that is the same as an existing key, the new value replaces the current value. When an input line contains a new key, the new key and value are made part of the entity. For example, to change the value of fs_server for the entity displayed in the previous example, use this entity command: entity NS@ORB { fs_server false } To remove a key and value from an entity, use the entitydeletekey command. For example, to delete the key use_comm_server and its value from the NS@ORB entity, use this command: entitydeletekey NS@ORB use_comm_server Adding an Entity To add an entity to the configuration database, use the first technique described in Changing an Entity. When you use a new entity name, the subsequent keys and values define that entity. For example, the following entity command would create a new entity named tcp_client@orb: entity tcp_client@orb { tsmp_client false fs_client false } Deleting an Entity To delete an entity (along with its keys and values) from the configuration database, use the entitydelete command. For example, to delete an entity named app_profile@orb, use this command: entitydelete app_profile@orb Exiting cfgmgt When you are finished using cfgmgt, return to the OSS command prompt by entering one of the following commands: bye exit quit Managing NonStop CORBA Processes

54 The nsdstart script configures and starts the various processes that comprise the NonStop Services for CORBA. These processes run under the TS/MP environment that provides them with capabilities such as auto-restart and scalability. After being started, the NonStop Services for CORBA are ready to receive and process requests. The nsdstop script shuts down the processes that comprise the NonStop Services for CORBA. After stopping the NonStop CORBA system, you must use the nsdstart script to restart the processes. Note: An alternative to using these scripts in the OSS environment is to use the Console to start and stop the servers. Note: The nsdstart script provided at product installation represents a basic configuration. The basic configuration is sufficient to run all the sample programs and might be appropriate for some production environments. You might want to change the configuration for example, to provide additional server processes or to change process priorities. Instructions for changing the configuration are provided below. If you use the Console to change your configuration, the nsdstart script is not changed to reflect these changes. If you want to use the nsdstart script in this situation, you must make corresponding changes to the script. The scripts are in the bin directory of the product installation. Starting and Stopping NonStop Services for CORBA Running nsdstart Running nsdstop Running nsdstart Before running nsdstart, be sure the required environment variable settings are in effect. To run the nsdstart script, enter the following command at the OSS command prompt: nsdstart This command starts the set of processes that comprise the NonStop Services for CORBA. A message similar to the following indicates that the processes have been started successfully: gtacl[9]: warning: unable to propagate all environment variables gtacl[9]: warning: unable to propagate all environment variables NSDOM runtime environment was started. Alternatively, you can run the nsdstart script in a manner that produces additional output as the script is executed by using the -v option as follows: nsdstart -v The additional output shows the script as it is executed. This mode of running nsdstart can be useful for troubleshooting configuration errors. To verify whether NonStop CORBA is running, type the following command (assuming NonStop CORBA is installed in the default nsdoms directory): ps e grep nsd You should see output similar to this: ? 00:00 /usr/tandem/nsdoms/bin/ilsd ? 00:00 /usr/tandem/nsdoms/bin/name_servant ? 00:00 /usr/tandem/nsdoms/bin/lsd ? 00:00 /usr/tandem/nsdoms/bin/cs ? 00:00 /usr/tandem/nsdoms/bin/eventservice ? 00:00 /usr/tandem/nsdoms/bin/ird ? 00:00 /usr/tandem/nsdoms/bin/nsotstm If you do not see output like this, you can restart the NonStop CORBA processes with the nsdstart script. Running nsdstop Before running nsdstop, be sure the required environment variable settings are in effect. To run the nsdstop script, enter the following command at the OSS command prompt: nsdstop This command stops the set of processes that comprise the NonStop Services for CORBA. The nsdstop script does not output a message when it completes. How the nsdstart Script Works Each time it is run, the nsdstart script does the following: 1. Sets the script variables that specify the NonStop CORBA process names, such as the process names for the Comm Server and Naming Server. 2. Determines the home terminal (hometerm) on which server output messages are displayed.

55 3. Starts the PATHMON process that manages the server processes. 4. Creates a new TS/MP configuration file using the server pool settings contained in the script. Some process names are defined using the script variables from Step Starts all the defined server processes. The configuration settings defined by the script are stored in a TS/MP configuration file (PATHCTL). This file is created in the directory given by the _DEFAULTS define in effect when the script is executed. For details about the PATHMON process and the PATHCOM commands used in the scripts, see the NonStop TS/MP System Management Manual. Troubleshooting: Problems Starting NonStop Services for CORBA Process Name in Use Pathctl File in Use Process Name in Use If you try to execute nsdstart when the target TS/MP environment is already running, you get an error message. The following example shows the result of executing the nsdstart file when the TS/MP environment for NonStop CORBA is already running. Issuing the nsdstart Command: Error Condition /usr/tandem/nsdoms> nsdstart -v gtacl[5]: unable to run $SYSTEM.SYSTEM.PATHMON, error (11, 12): \ process name error - The file is in use $Z070: PATHCOM - T8344D42 - (03JUN96) COPYRIGHT TANDEM COMPUTERS INCORPORATED , = = set pathway maxassigns 8 set pathway maxassigns 8 ^ $Z070: ERROR - *1009* PATHWAY CONFIGURATION CAN'T BE CHANGED Pathctl File in Use If the TS/MP configuration file is in use, you see an error similar to this: $Z1XY: ERROR - *1017* PATHCTL FILE (012) To remedy this error, define an alternate location for the TS/MP configuration file by entering the following command at the OSS command prompt: add_define =_DEFAULTS class=defaults volume=\$vol.subvol Substitute the desired volume name for VOL and the desired subvolume name for SUBVOL. After executing this command, executing the nsdstart script causes the TS/MP configuration file to be created in the specified location. Differences Between Using Scripts and Using the PATHCOM Interface Scripts enable you to start or stop an entire configuration by executing a single command. Thus, if you need to change the global parameters in your TS/MP configuration, you might edit them in the nsdstart file and then execute the script. (If your NonStop CORBA system is running, you must execute the nsdstop script before restarting the system with the nsdstart script.) The nsdstart script includes PATHCOM commands that refer to server classes (server class is the TS/MP term for server pool). However, if you need to restart a TS/MP configuration whose global configuration parameters have not changed, you can use PATHCOM, the interface to the PATHMON process. Similarly, if you need to change the attributes of a single server pool or server process, you do not need to shut down the entire TS/MP environment. You can modify one or more server processes more efficiently by using the PATHCOM interface, as described in Using the PATHCOM Interface to Maintain TS/MP Processes. Customizing the nsdstart Script By default, the configure script starts the following processes: Servers Started (1 each) Default Process Names Process Priority BSD System assigned 150 LSD System assigned 150 ILSD System assigned 150 Comm Server $ZNCA 150 Event Service System assigned 160 Naming Service $ZND0 170 Object Transaction Service $ZNO0 150 Interface Repository Daemon $ZNDI 160

56 OTS XID (if OTS static servers are greater than one) $ZNXI 150 You might want to customize the nsdstart script to your needs. You can: Changing the process priority Changing the CPU in which a server runs Enabling tracing output for a server Adding a Comm Server process Removing a Comm Server process Manage a NSots transaction manager in a process pool To change the script: 1. Give write permission to the script file nsdstart by using the chmod command. 2. Edit the script, making the desired changes. You can use the vi editor under OSS. 3. Save the changes. Changing the Process Priority 1. Locate the section of the script that defines the server you want to change. 2. Change the process priority number in the line that looks like this: set server pri 150 Changing the CPU in Which a Server Runs 1. Locate the section of the script that defines the server you want to change. 2. Add a line similar to the following (which specifies that the servers should run in CPUs 1 and 2): set server cpus (1,2) Enabling Trace Output for a Server 1. Locate the section in the script for the server you want to change. 2. Find the lines that enable tracing. These lines are initially commented out (the left bracket comment character "[" appears in front of each line). 3. Remove the comment character from each trace line. 4. After you restart the server, trace output appears in the log file. For log file information, see Appendix D. Adding a Comm Server Process Assume that the currently running NonStop CORBA system includes a Comm Server named $ZNCA and that you want to add a second one named $ZNCB. Note: The examples in this section assume that you have set MY_PREFIX in the env.sh script equal to the value Z. 1. If NonStop CORBA system processes are running, stop them by executing the nsdstop script from OSS: > nsdstop 2. Locate the Comm Server specification section in the nsdstart script. The following example shows the section of nsdstart that configures the Comm Server process: Configuring a Comm Server #... COM_SERVER1="$MY_PREFIX"NCA COM_SERVER2="$MY_PREFIX"NCB #... set server maxservers 1 set server numstatic 1 set server process \$$COM_SERVER1 set server AUTORESTART 10 add server CS start server CS # Edit this section to add another server. Note that new Comm Servers names must have the last letter incremented, giving Comm Servers $ZNCA through $ZNCZ. There is a limit of 26 Comm Servers.

57 Adding a Comm Server to the nsdstart Script #... COM_SERVER1="$MY_PREFIX"NCA COM_SERVER2="$MY_PREFIX"NCB #... set server maxservers 2 set server numstatic 2 set server process \$$COM_SERVER1 set server process \$$COM_SERVER2 set server AUTORESTART 10 add server CS start server CS # Be sure you add the new Comm Server profile for the process $ZNCB to the configuration database. See Configuration and Adding an Entity for details. 5. Restart NonStop CORBA system processes by executing the nsdstart script from OSS: > nsdstart Removing a Comm Server Process Assume that the current NonStop CORBA system is configured to include two Comm Servers, named $ZNCA and $ZNCB, and you want to remove the $ZNCB process. 1. If NonStop CORBA system processes are running, stop them by executing the nsdstop script from OSS: > nsdstop 2. Locate the Comm Server specification section in nsdstart. The following example shows the section of nsdstart that configures the Comm Server, including two processes: Configuring Two Comm Servers #... COM_SERVER1="$MY_PREFIX"NCA COM_SERVER2="$MY_PREFIX"NCB #... set server maxservers 2 set server numstatic 2 set server process \$$COM_SERVER1 set server process \$$COM_SERVER2 set server AUTORESTART 10 add server CS start server CS # Edit the section to remove the $ZNCB server process, as follows: Removing a Comm Server From nsdstart #... COM_SERVER1="$MY_PREFIX"NCA #... set server maxservers 1 set server numstatic 1 set server process \$$COM_SERVER1 set server AUTORESTART 10 add server CS start server CS # Restart the NonStop CORBA system processes by executing the nsdstart script from OSS: > nsdstart Managing NSots Transaction Managers in a Process Pool To support two or more NSots transaction managers in a process pool, it is necessary to run a NSots XID Broker process. The XID Broker brokers requests for imported transactions within the pool of NSotsTMs by routing secondary import requests back to the NSotsTM that originally imported the transaction. If only more than one NSotsTM process is configured in a process pool, it is necessary to also configure one and only one NSotsXID process. It is also necessary to define the environment variable NSOTS_XID_BROKER_REQUIRED for the NSotsTM process. These steps are shown in commentary form in the nsdstart script. They are also supported by the Console. If NSOTS_XID_BROKER_REQUIRED is defined and NSotsXID is not available, the application should receive the exception CORBA::TRANSIENT. Configuring NonStop CORBA to Use Parallel Library TCP/IP When NonStop CORBA is initially installed the default configuration is for the original TCP/IP. To configure Parallel Library TCP/IP, perform the

58 following steps: 1. During installation, provide a Parallel Library TCP process name to the prompt beginning: "ENTER the TCP process name here..." The default TCP process name for original TCP/IP is $ZTC0. The default TCP process name for Parallel Library TCP/IP is set when Parallel Library TCP/IP is installed. You can locate the Parallel Library TCP/IP process for your system by using the SCF command LISTDEV TCPIPand looking for a process with program path ending in TCPSAM. 2. Before starting the subsystem, configure the BSD, LSD, ILSD, and Comm Server(s) to take advantage of Parallel Library TCP/IP. Note: If you want to change from original TCP/IP to Parallel Library TCP/IP after the initial installation of NonStop CORBA, it is easier to use the Console to make the changes, due to the number of configuration database changes that must be made. Configuring the BSD, LSD and ILSD for Parallel Library TCP/IP The same procedure is required to configure the BSD, LSD and ILSD. Apply this procedure to the BSD server class, LSD server class and/or the ILSD server class. 1. Use the cfgmgt tool to add the key/value pair parallel_ip/true to the application's profile. For example: [dbname:$system.zorbsdk.nsdcfgdb] 1>entity lsd1@orb {parallel_ip true} This profile change tells the TCP/IP component of the NonStop CORBA application to tell the Parallel Library TCP/IP components to enable socket sharing and round-robin connection filtering. 2. Alter the application's SERVERCLASS configuration in the nsdstart script to run multiple processes. This involves changing the maxservers and numstatic entries, and creating the appropriate process entries. Note: Each process in a Parallel Library TCP/IP server class must run in a separate CPU. Example 4.1. Parallel Library TCP/IP LSD The following portion of nsdstart will configure a Parallel Library TCP/IP LSD with three processes running in CPUs 1, 2, and 3, named $lsd1, $lsd2, and $lsd3, respectively. The lines that have been altered are indicated by a "+". The lines that have been added are indicated by a "*". [ configure LSD reset server set server processtype oss set server pri 150 set server cwd $MY_ROOT set server program $NSD_ROOT/bin/lsd set server hometerm $G_HOMETERM set server stdin /dev/null set server stdout $MY_ROOT/log/lsd.log set server stderr $MY_ROOT/log/lsd.log set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM set server env MY_PREFIX=$MY_PREFIX set server define =_RLD_LIB_PATH, class map, file $NSD_SRL_SUBVOL.NSDDLL set server createdelay 0 secs set server deletedelay 0 secs set server TIMEOUT 0 SECS set server MAXLINKS 16 set server LINKDEPTH 1 + set server maxservers 3 + set server numstatic 3 * set server process \$lsd1 (CPUs 1) * set server process \$lsd2 (CPUs 2) * set server process \$lsd3 (CPUs 3) set server AUTORESTART 10 set server arglist "-ORBprofile", "lsd1" add server LSD start server LSD Example 4.2. Parallel Library TCP/IP BSD The following portion of nsdstart will configure a Parallel Library TCP/IP BSD with three processes running in CPUs 1, 2, and 3, named $bsd1, $bsd2, and $bsd3, respectively. The lines that have been altered are indicated by a "+". The lines that have been added are indicated by a "*". [ configure BSD reset server set server processtype oss set server pri 150 set server cwd $MY_ROOT

59 set server program $NSD_ROOT/bin/bsd set server hometerm $G_HOMETERM set server stdin /dev/null set server stdout $MY_ROOT/log/bsd.log set server stderr $MY_ROOT/log/bsd.log set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM set server env MY_PREFIX=$MY_PREFIX set server define =_RLD_LIB_PATH, class map, file $NSD_SRL_SUBVOL.NSDDLL set server createdelay 0 secs set server deletedelay 0 secs set server TIMEOUT 0 SECS set server MAXLINKS 16 set server LINKDEPTH 1 + set server maxservers 3 + set server numstatic 3 * set server process \$bsd1 (CPUs 1) * set server process \$bsd2 (CPUs 2) * set server process \$bsd3 (CPUs 3) set server AUTORESTART 10 set server arglist "-ORBprofile", "bsd1" add server BSD start server BSD Configuring a Comm Server for Parallel Library TCP/IP Use this procedure to change the default Comm Server configuration into a Parallel Library TCP/IP Comm Server. 1. Use the cfgmgt tool to add the key/value pair parallel_ip/true to the default@orb entity. For example: [dbname:$system.zorbsdk.nsdcfgdb] 1>entity default@orb{parallel_ip true} This tells the Comm Servers to use the Parallel Library TCP/IP approach to dynamic mapping (round robin) instead of the original TCP/IP approach (load based). 2. Alter the default Comm Server SERVERCLASS configuration in the nsdstart script to pass the Comm Server's key as an argument. This involves adding a statement to set the server's arglist. Alter the default Comm Server SERVERCLASS configuration to run multiple processes. This involves changing the maxservers and numstatic entries, and creating the appropriate process entries. Note: Each process in a Parallel Library TCP/IP server class must run in a separate CPU. Example 4.3. Parallel Library TCP/IP Comm Server The following portion of nsdstart will configure a Parallel Library TCP/IP Comm Server with three processes running in CPUs 1, 2, and 3, named $cs1, $cs2, and $cs3, respectively. The lines that have been altered are indicated by a "+". The lines that have been added are indicated by a "*". The line that has been commented out is indicated by a "-". [ configure comm server(s) reset server set server processtype oss set server pri 150 set server cwd $MY_ROOT set server program $NSD_ROOT/bin/cs set server hometerm $G_HOMETERM set server stdin /dev/null set server stdout $MY_ROOT/log/cs.log set server stderr $MY_ROOT/log/cs.log set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM set server define =_RLD_LIB_PATH, class map, file $NSD_SRL_SUBVOL.NSDDLL set server createdelay 0 secs set server deletedelay 0 secs set server TIMEOUT 0 SECS set server MAXLINKS 16 set server LINKDEPTH 1 + set server maxservers 3 + set server numstatic 3 - [set server process \$$COM_SERVER1 * set server arglist "$COM_SERVER1" * set server process \$cs1 (CPUs 1) * set server process \$cs2 (CPUs 2) * set server process \$cs3 (CPUs 3) set server AUTORESTART 10 add server CS start server CS Configuring Additional Parallel Library TCP/IP Comm Servers

60 Additional Parallel Library TCP/IP Comm Servers can be configured by adding a Comm Server SERVERCLASS under TS/MP, and adding a Comm Server entity in the configuration database. To add a second Comm Server SERVERCLASS, duplicate the entire section of nsdstart that configures the default Comm Server. Also, make sure the MAXSERVERCLASSES attribute of the PATHMON configuration accounts for this extra SERVERCLASS. The following names must be unique: 1. SERVERCLASS name. The default Comm Server SERVERCLASS name is CS. A second Parallel Library TCP/IP Comm Server SERVERCLASS might have the name CS2. Using the example above as a reference, the last two lines would be: add server CS2 start server CS2 The SERVERCLASS name has no constraints beyond those required by TS/MP. 2. Process names. In the above example, we used the process names $cs1, $cs2, and $cs3. A second Comm Server SERVERCLASS might use the following statements: * set server process \$csb1 (CPUs 1) * set server process \$csb2 (CPUs 2) * set server process \$csb3 (CPUs 3) Note that the '$' must be escaped with a '\' because nsdstart is a PATHCOM script embedded in an OSS shell script. Constraints 1. The Comm Server name must be passed as an argument to the processes in a Parallel Library TCP/IP Comm Server SERVERCLASS. The line in the example above that does this is: * set server arglist "$COM_SERVER1" This Comm Server name must conform to the following convention: CSNAME = PNCX where P is the installation prefix (the default is Z) and X is a letter that must be in contiguous ascending order. The letters in CSNAME must be all upper case. If the default Comm Server's name is ZNCA, a second Comm Server's name must be ZNCB. There are two handy predefined Comm Server name variables available in the nsdstart script, COM_SERVER1 and COM_SERVER2. 2. The Comm Server entity name must have the following form: csname@comm_server where csname is the argument passed to processes in the associated Parallel Library TCP/IP Comm Server SERVERCLASS. 3. The Comm Server entity must specify: a parallel library TCP/IP process for the tcp_process entry a host_name entry that corresponds to the tcp_process entry a unique value for the port_number entry Nonconstraint Processes from different Parallel Library TCP/IP SERVERCLASS objects may be configured in the same CPU. Using the PATHCOM Interface to Maintain TS/MP Processes You configure NonStop CORBA system server processes by using the services of TS/MP. Processes defined through TS/MP run under the control of a TS/MP monitor, the PATHMON process. PATHCOM provides the interface to the PATHMON process. You begin a PATHCOM process from the TACL prompt in the Guardian environment. For detailed instructions about starting these processes, and for complete syntax and descriptions for all PATHCOM commands, refer to the NonStop TS/MP System Management Manual. This subsection gives an overview of how you can use PATHCOM to alter global and process-specific configuration parameters in the TS/MP configuration. Maintenance and fine-tuning tasks for NonStop CORBA system and application processes include the following: Monitoring status and performance by using the PATHCOM interface to display information about the TS/MP environment and the server pools. Modifying global parameters based on changing requirements. Adding, removing, or modifying server pools and processes based on performance queues or changing requirements. Making changes based on performance considerations, including load-balancing issues.

61 Using the PATHCOM Interface The OSS scripts supplied with NonStop CORBA enable you to issue a single command to start (or stop) a TS/MP configuration. Although these scripts are good for starting and stopping all NonStop CORBA system processes, they lack the control you need to properly administer a running system. The nsdstart script causes PATHMON to re-create the entire TS/MP configuration file, a potentially lengthy process. If your global configuration parameters have not changed, you do not need to re-create this configuration file. By using PATHCOM, you can directly administer a PATHMON process without re-creating the existing TS/MP system configuration. Starting a PATHMON Process To issue PATHCOM commands, you must first start a PATHCOM process to communicate with the PATHMON process that controls your TS/MP environment. Type the following from the TACL prompt: > PATHCOM $pmon This command begins a PATHCOM session that uses the PATHMON process names in the $pmon parameter, for example, $ZNDM. The system responds by returning the PATHCOM prompt: = Restarting a Previously Defined TS/MP Configuration You can use the PATHCOM interface to restart a NonStop CORBA system process. To do so: 1. Start a PATHCOM process to communicate with the running PATHMON process. 2. Stop and restart a NonStop CORBA process. Consider the following commands: > PATHMON /NAME $ZNDM, NOWAIT/ > PATHCOM $ZNDM = FREEZE NS = STOP NS = THAW NS = START NS Assume you want to restart the naming service processes. These processes are defined in the NS server class. The freeze and stop commands cause PATHMON to stop the processes. The thaw and start commands restart the processes. Monitoring Status The PATHMON process maintains information about process configurations, process status, and operations statistics. The following table lists the PATHCOM commands and their effects: PATHCOM Commands PATHCOM Commands Effect INFO Returns current configuration information STATUS Returns the current state of a process, for example: RUNNING, STOPPED, or SUSPENDED STATS Returns process usage statistics Most status and statistics information collected by these commands is collected by the Pathsend API and the LINKMON process. The Pathsend API provides procedure calls that are used by clients to access TS/MP server processes. The LINKMON process is a link manager that provides link management functions for Pathsend requests. Note: Statistics information is not available for the Comm Server and the LSD because they are not accessed by the Pathsend API or the LINKMON process, which collect the information. Status and statistics information is available, however, for the Naming Server and Event Server and for all TS/MP application server processes. Displaying Configuration Information Use the INFO command to display configuration information. You can display configuration information about your overall TS/MP environment, about the PATHMON process, or about specific server pools in the environment by using the following commands: INFO PATHWAY INFO PATHMON INFO SERVER INFO PATHWAY Command To display global parameters for the overall TS/MP environment, type the following:

62 = INFO PATHWAY The example below shows the information displayed when you execute the INFO PATHWAY command for the TS/MP environment: INFO PATHWAY Display =info pathway PATHWAY MAXASSIGNS 8 [CURRENTLY 0] MAXDEFINES 27 [CURRENTLY 4] MAXEXTERNALTCPS 0 [CURRENTLY 0] MAXLINKMONS 16 [CURRENTLY 0] MAXPARAMS 4 [CURRENTLY 0] MAXPATHCOMS 8 [CURRENTLY 1] MAXPROGRAMS 4 [CURRENTLY 0] MAXSERVERCLASSES 4 [CURRENTLY 4] MAXSERVERPROCESSES 40 [CURRENTLY 8] MAXSPI 8 [CURRENTLY 0] MAXSTARTUPS 4 [CURRENTLY 0] MAXTCPS 0 [CURRENTLY 0] MAXTELLQUEUE 4 MAXTELLS 32 [CURRENTLY 0] MAXTERMS 0 [CURRENTLY 0] MAXTMFRESTARTS 5 OWNER \OSS2.190,0 SECURITY "N" = This output shows current values of the global TS/MP environment variables. These variables are set by the nsdstart shell script, or by using the SET PATHWAY command to enter the values manually. Note: Several parameters are not relevant for NonStop CORBA applications, and should be set to zero when you configure the NonStop CORBA system. These parameters include MAXEXTERNALTCPS, MAXTCPS, and MAXTERMS. From TS/MP 2.3 onwards the default Pathway security setting is 0 (zero). The Pathway security setting can be changed to the required value using SET PATHWAY SECURITY in the nsdstart script. Executing the INFO command lets you determine whether current global limits are being reached, because the display shows maximum limits on the left and actual current totals on the right. In the above example, the configuration allows a maximum of 40 server processes to be running at any given time. The current total is 8 server processes running. To see complete syntax and descriptions for all global parameters, refer to the NonStop TS/MP System Management Manual. INFO PATHMON Command To display information about parameters set for the PATHMON process, type the following PATHCOM command: = INFO PATHMON The following example shows information displayed after the INFO PATHMON command was issued: INFO PATHMON Display PATHMON BACKUPCPU 4 DUMP ON (FILE \SYS.$VOL1.TESTING.MONDUMP) This sample display shows the PATHMON backup process running in CPU 4. If the PATHMON process encounters an internal error, it writes data-stack information to \SYS.$VOL1.TESTING.MONDUMP. INFO SERVER Command The following example shows the command you would type to display the configuration parameters for a single server pool: = INFO SERVER CS In this command, CS is the logical name defined for the server class in the TS/MP configuration. In this example, the command displays parameters for the Comm Server. The parameters are the attributes defined through the SET SERVER command when the TS/MP configuration was created by the nsdstart script or through the PATHCOM interface. INFO SERVER Display = info server cs SERVER CS PROCESSTYPE OSS AUTORESTART 10 CREATEDELAY 0 SECS CWD /cust7/r1488.user/tandem/nsd2.3/nsd.e05 DEBUG OFF DEFINE =_RLD_LIB_PATH,CLASS MAP, FILE \OSS2.$DATA07.NSDE5.NSDDLL DELETEDELAY 0 SECS ENV NSDOM_CFG_DBM=$DATA07.NSDE5.NSDCFGDB HIGHPIN OFF HOMETERM \OSS2.$ZTN0.#PTPFULC LINKDEPTH 1 MAXLINKS 16 MAXSERVERS 2 NUMSTATIC 2 OWNER \OSS2.190,0

63 = PRI 150 PROCESS $YC01 (CPUs 0:1) PROCESS $YC02 (CPUs 1:0) PROGRAM /cust7/tandem/nsd2.3/nsd.e05/bin/cs SECURITY "N" STDERR /cust7/tandem/nsd2.3/nsd.e05/log/cs.out STDIN /dev/null STDOUT /cust7/tandem/nsd2.3/nsd.e05/log/cs.out TIMEOUT 0 SECS TMF OFF VOLUME \OSS2.$DATA07.DEREK Displaying Status Information Use the STATUS command to display status information about your TS/MP environment, the PATHMON process itself, and server objects. Displaying Environment Status To display status for the overall TS/MP environment, issue the following PATHCOM command: = STATUS PATHWAY The following command gives you a display showing the state of the environment (for example, RUNNING). The display also shows how many server pools, server processes, and LINKMON processes are running, stopped, thawed, and so on: STATUS PATHWAY Display = status pathway PATHWAY -- STATE=RUNNING RUNNING EXTERNALTCPS 0 LINKMONS 0 PATHCOMS 1 SPI 0 FREEZE RUNNING STOPPED THAWED FROZEN PENDING SERVERCLASSES RUNNING STOPPED PENDING SERVERPROCESSES TCPS RUNNING STOPPED PENDING SUSPENDED TERMS = Displaying PATHMON Status To display information about the PATHMON process, type the following: = STATUS PATHMON The STATUS command displays information about where the PATHMON process is running, where the PATHMON configuration files are located, and whether log files are open: STATUS PATHMON Display = status pathmon PATHMON \OSS2.$YNSD2 -- STATE=RUNNING CPUs 1:0 PATHCTL (OPEN) $DATA07.DEREK.PATHCTL LOG1 S (CLOSED) \OSS2.$Z6GR.#INTER ERROR=201 LOG2 (CLOSED) REQNUM FILE PID PAID WAIT 1 PATHCOM $Z7YJ 190,0 = Displaying Server Pools Status To display status information, type the following: = STATUS SERVER *, DETAIL You get a display showing the number of server processes running, errors, the number of links, and the weight. STATUS SERVER Display =status server *,detail SERVER CS #RUNNING 1 ERROR INFO PROCESS $ANCA STATE RUNNING ERROR INFO #LINKS WEIGHT 0 0 SERVER ES #RUNNING 1 ERROR INFO PROCESS $Z02V STATE RUNNING ERROR INFO #LINKS WEIGHT 0 0 SERVER ILSD #RUNNING 1 ERROR INFO

64 PROCESS $Z02W STATE RUNNING ERROR INFO #LINKS WEIGHT 0 0 SERVER IRD #RUNNING 1 ERROR INFO PROCESS $Z02X STATE RUNNING ERROR INFO #LINKS WEIGHT 0 0 SERVER LSD #RUNNING 1 ERROR INFO PROCESS $Z02Y STATE RUNNING ERROR INFO #LINKS WEIGHT 0 0 SERVER NS #RUNNING 1 ERROR INFO PROCESS STATE ERROR INFO #LINKS WEIGHT $AND0 RUNNING 5 15 SERVER #RUNNING ERROR INFO OTSTM = PROCESS STATE ERROR INFO #LINKS WEIGHT $ANO0 RUNNING 9 17 Using the STATUS SERVER command can help you determine whether links are evenly allocated and balanced among server processes in your NonStop CORBA application environment. The #LINKS field shows the total number of current links to a given server process. The WEIGHT field indicates how heavily the server process is used relative to how heavily other processes in the server pool are used. In the example above, process $ANO0 has nine links and a weight of 17; thus it is the hardest working process in the server pool at the moment. Displaying Statistical Information To display statistical information about a PATHMON process, type the following PATHCOM command: = STATS SERVER PROCESS-SERVER Refer to the TS/MP System Management Manual for details about interpreting the output from this command. Modifying Global Parameters Based on Changing Requirements As your application needs change, requirements for your TS/MP configuration will change. If your application grows, adjustments might be necessary to satisfy your transaction throughput and response-time requirements and to update or expand the system to provide needed resources. For example, you might need to increase the maximum number of application-server processes to satisfy a growing demand for links to servers. In response to your changing requirements, you might need to specify not just new attributes for your server pools but also new global limits and parameters for the TS/MP environment. Caution: You cannot specify new global parameters while the PATHMON environment is running. You must first shut down the entire configuration before you can install the new parameters. Because a system shutdown can result in considerable downtime if your application is complex, when you first configure your environment you should specify global limits that are high enough to allow for growth. If you discover that you must reconfigure the global parameters, thereby forcing a shutdown, you must re-specify all limits, not just the ones you are changing. For this reason, you might find it more efficient to change global parameters by editing the nsdstart script rather than specifying each specific parameter through PATHCOM. If you change global parameters by editing the relevant parameters in the nsdstart script, execute the script to cold-start the TS/MP environment with the new parameters. If you use PATHCOM to respective all parameters, be sure to use the COLD start option of the SET PATHWAY command to restart the TS/MP environment. Reconfiguring Server Pools Changing application requirements or performance queues can necessitate a reconfiguration of your server resources. For example, you may find that one application server pool is handling many more requests than expected while another does not receive the expected number of requests. One way to address this situation would be to increase the maximum number of processes that can be started for the first server pool. A more complex approach might be to review link access to the first server pool and modify link-related server attributes such as LINKDEPTH and MAXLINKS. For a discussion of these attributes and ways to use them to achieve successful load balancing across server processes, refer to Load Balancing for Application Server Processes. You do not need to shut down the environment to reconfigure server pools. Because editing and running the nsdstart script requires a complete environment shutdown, reconfiguring server pools by using the appropriate PATHCOM commands may be more efficient.

65 Adding a Server Pool To add a server pool, use the SET SERVER and ADD SERVER commands. Then use the START SERVER command to start the pool. For details about how to do this, refer to the nsdstart script. Modifying Running Server Pools To remove or alter a running server pool, you must: 1. Freeze the server pool 2. Stop the server pool 3. Delete or modify the server pool 4. Thaw the modified server pool 5. Start the modified server pool Stopping a Running Server Pool Before you can modify a running server pool, you must stop it. First, use the FREEZE SERVER command to disable server communications with other processes in the environment. After a server pool is frozen, you can stop it by issuing a STOP SERVER command. For example, the following commands stop all server processes in server pool NS: = FREEZE SERVER NS = STOP SERVER NS To stop all server pools in your TS/MP configuration, use the following two commands: = FREEZE SERVER * = STOP SERVER * To confirm that server pools are frozen or stopped, use the STATUS SERVER command. Once the server pool is stopped, you can use PATHCOM commands to either delete the server pool or to modify the server attributes. Restarting a Server Pool To restart server pool NS, you must first thaw the server, then start it, as shown: = THAW SERVER NS = START SERVER NS The following commands restart all server processes: = THAW SERVER * = START SERVER * Altering a Server Pool Alter a server pool by using the ALTER SERVER command. For example, the following series of commands changes the priority at which the server CS runs: ALTER SERVER Command = FREEZE SERVER CS = STOP SERVER CS = ALTER SERVER CS, PRI 50 = THAW SERVER CS = START SERVER CS Note that the FREEZE command precedes the STOP and ALTER commands; and also note that the THAW command must precede the START command. Managing the Distributed Object Environment This subsection provides an overview of the tasks involved with managing the NonStop CORBA distributed object environment. The NonStop CORBA system implements the ORB on the NonStop Kernel operating system. Managing this environment includes monitoring the system processes contained in the NonStop CORBA system, monitoring the underlying networking resources, tuning the system configuration for performance, and troubleshooting the ORB. The Distributed Object Environment The figure below shows some of the major components of the NonStop CORBA system runtime environment and the tools you use to manage each type of component.

66 NonStop CORBA Configuration Management The NonStop CORBA system is implemented as an application using TS/MP, which provides for scalability and load balancing by allowing multiple processes to work in parallel to perform the same task. TS/MP also provides for availability: its monitor process, called PATHMON, automatically restarts a process that fails. Because TS/MP provides all process management for the NonStop CORBA system, you use TS/MP interfaces to configure and manage the NonStop CORBA system processes. The user interface of TS/MP is a line-oriented utility called PATHCOM. PATHCOM includes commands for setting and reviewing configuration options, starting and stopping processes, and gathering information about process status and utilization. You can use PATHCOM interactively or by means of command files. You can also write applications that use the Subsystem Programmatic Interface (SPI) to perform any function available through PATHCOM. To define and maintain the configuration of networking resources, such as TCP/IP, you use the Subsystem Control Facility (SCF) or write an application that uses the SPI. The SCF and corresponding programmatic interfaces include commands for setting and reviewing configuration options and for gathering information about the status and use of communication lines, processes, and related resources. NonStop CORBA Performance Tuning Performance tuning of the runtime environment of the NonStop CORBA system is primarily a matter of deciding on the number and relationships among Location Service Daemon (LSD), Comm Server, and TCP/IP processes: 1. You use PATHCOM to define the number of Comm Servers. 2. You use the Configuration Tool to define the relationships among the LSD, Comm Servers, TCP/IP processes, remote clients, and application servers. 3. You can use PATHCOM to locate and resolve a NonStop CORBA system performance problem. 4. You can use the cfgmgt tool and the nsdstart script to configure Parallel Library TCP/IP to increase capacity. The use of underlying networking services (X25AM and LAN) by TCP/IP can also affect the performance of the NonStop CORBA runtime environment. You use SCF to establish and monitor those relationships. Caution: NonStop CORBA does not use TS/MP to provide automatic load balancing for Comm Servers. Instead, the relationships among clients and the Comm Servers are fixed by the LSD configuration. Thus, assumptions about TS/MP load balancing and performance tuning will not always apply to managing the NonStop CORBA runtime environment. For example, a bottleneck could occur in a Comm Server even if other servers in the pool were idle; in this case,

67 you would improve performance by using the cfgmgt to modify the assignment of clients to Comm Servers rather than by using PATHCOM to add Comm Server processes. Often a perceived problem with NonStop CORBA system performance is actually the result of application design and configuration, such as the use of requests to stateful objects and the locations and design of objects that frequently exchange data. NonStop CORBA Troubleshooting The most common problems preventing successful operation of the NonStop CORBA system are the following: Configuration errors Inconsistencies in configuration between the NonStop CORBA system and another system with which it must communicate Other interoperability problems, such as differing implementations of a CORBA-defined feature on different platforms Transient networking failures Resolving a problem that arises in the interaction between the NonStop CORBA system and some other ORB typically requires collaboration with the remote administrator. In this case your best tool is a full, up-to-date set of the NonStop CORBA and SCF configuration files. However, several automated tools can also help you troubleshoot your local NonStop CORBA system: PATHCOM lets you verify the current configurations of NonStop CORBA runtime processes. The NonStop CORBA error log is the primary source of information about NonStop CORBA execution errors. A variable in the NonStop CORBA configuration file controls the error logging. The NonStop CORBA trace facility lets you follow the flow of control in an application to discover when and where an error occurred. Each component has a variable in the configuration file that controls the tracing for that component. SCF lets you verify the configuration of networking resources, validate addressing information, discover recurrent errors, and obtain line traces and protocol traces. The Ptrace utility helps you to interpret SCF traces. The Event Management Service (EMS), which has several interactive and programmatic interfaces, helps you capture and integrate the error information reported by different processes including TS/MP, NonStop TM/MP, the operating system, and the networking services. See the EMS Manual for descriptions of the EMS interfaces. Chapter 3. Configuration and Management Using the Console Chapter 5. Managing Application Processes

68 Chapter 5. Managing Application Processes Chapter 5. Managing Application Processes The Application Environment Application Configuration Management Application Performance Tuning Managing NonStop CORBA applications, like managing the NonStop CORBA system, consists of tasks such as configuring and monitoring the application processes, tuning system performance, and troubleshooting. When you install NonStop CORBA application servers, you have the option to configure them as TS/MP server pools. This configuration is recommended because you get the advantages of availability and scalability that server pools offer. Configuring your servers to run in server pools means that you must run your application servers under a PATHMON process that is specially configured for your servers. The easiest way to set up this PATHMON process is to copy and edit the script files that configure and start the NonStop CORBA system. This section provides an overview of the tasks needed to manage the application components that run in the NonStop CORBA environment. For further information see NonStop CORBA Programmer's Guide for C++ or NonStop CORBA Programmer's Guide for Java. The Application Environment The figure below shows some types of application entities you might need to manage: stateless server pools, stateful server pools, single processes (clients and servers), and a distributed database.