BASEstar_Open_Server_for_UNIX_______________________ Inst. & Management Guide Order Number: AA-QSD6A-TE February 1996 This guide provides instructions for installing BASEstar Open for UNIX on Digital and HP platforms. Revision/Update Information: This is a new document. Operating System and Version: Digital UNIX Version 3.2 HP-UX Version 10.0 Software Version: BASEstar Open Version 3.0 Digital Equipment Corporation Maynard, Massachusetts ________________________________________________________________ February 1996 © Digital Equipment Corporation 1996. All Rights Reserved. Possession, use, or copying of the software described in this documentation is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. The postpaid Reader's Comments forms at the end of this document request your critical evaluation to assist in preparing future documentation. The following are trademarks of Digital Equipment Corporation: Alpha AXP, BASEstar, DEC, DECmessageQ, DECnet, DECnet-DOS, DECosap, DEComni, Digital, Digital UNIX, FMS, LN03, MicroVAX, NAS, OpenVMS, OpenVMS Alpha, PATHWORKS, PDAS, Rdb/VMS, ReGIS, ThinWire, TK, ULTRIX, VAX, VAXcluster, VAX COBOL, VAX FORTRAN, VAX Pascal, VAX RMS, VMS/ULTRIX Connection, VT, and the DIGITAL logo. The following are third-party trademarks: Excel is a registered trademark of Microsoft Corporation. IBM is a registered trademark of IBM Corp. INGRES is a trademark of Ingres Corp. LOTUS 1-2-3 is a registered trademark of Lotus Development Corp. MS, Microsoft, and MS-DOS are registered trademarks of Microsoft Corporation. Network File System and NFS are trademarks of Sun Microsystems, Inc. ORACLE is a trademark of Oracle Corp. PostScript is a registered trademark of Adobe Systems Incorporated. SINEC AP, SINEC H1, SICOMP, Simatic, SINEC, SINUMERIK and SIROTEC are registered trademarks of Siemens, AG. UNIX is a registered trademark licensed exclusively by X /Open Company Ltd. Windows and Windows NT are trademarks of Microsoft Corporation. Wonderware InTouch is a registered trademark of Wonderware Corporation. X/Open is a registered trademark of the X/Open Company Limited This document was prepared using VAX DOCUMENT, Version 2.1. _________________________________________________________________ Contents Preface................................................... ix Installation Section - Digital UNIX 1 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.1 Release Notes.................................... 1-1 1.2 License Registration............................. 1-2 1.3 Checking the Media Software Distribution Kit..... 1-3 1.4 BASEstar Open Server Subsets..................... 1-3 1.5 Installation Procedure Requirements.............. 1-4 1.5.1 Checking Login Privileges ..................... 1-4 1.5.2 Hardware Requirements ......................... 1-4 1.5.3 Software Requirements ......................... 1-5 1.5.4 Determining Disk Space Requirements ........... 1-6 1.5.5 Increasing the Available Disk Space for BASEstar Open Server Installation.............. 1-8 1.6 Backing Up Your System Disk...................... 1-8 1.7 Stopping the Installation........................ 1-8 1.8 Error Recovery................................... 1-8 2 Installing BASEstar Open Server on a Digital UNIX System 2.1 Installing CD-ROM Consolidated Distribution Media............................................ 2-1 2.2 Responding to Installation Procedure Prompts..... 2-2 2.2.1 Selecting Subsets ............................. 2-2 2.2.2 Monitoring Displays During the Subset Loading Process........................................ 2-4 2.2.3 Running the IVP ............................... 2-4 iii 2.2.4 Setting Up and Starting the BASEstar Open Server Environment............................. 2-5 2.3 The Installation Verification Procedure.......... 2-5 2.3.1 Prerequisites and Constraints ................. 2-7 2.3.2 Running the Installation Verification Procedure...................................... 2-8 2.4 Reporting Errors................................. 2-8 2.5 Deleting BASEstar Open Server From Your System... 2-9 2.6 Displaying Documentation from CD-ROM............. 2-10 2.6.1 Using the Startup Files Created During the Installation................................... 2-10 3 Installing BASEstar CIMfast 3.1 Starting the Installation Procedure.............. 3-1 3.1.1 Using CD-ROM Consolidated Distribution Media .. 3-1 3.2 Responding to Installation Procedure Prompts..... 3-2 3.2.1 Selecting Subsets ............................. 3-2 3.2.2 Monitoring Displays During the Subset Loading Process........................................ 3-3 3.3 Completing the Installation...................... 3-3 3.3.1 Running the Installation Verification Procedure...................................... 3-4 3.3.2 Using the Startup Files Created During the Installation................................... 3-4 Environment Management Section 4 Introduction to Environment Management 4.1 Environment Management Overview.................. 4-1 4.2 Environment and Application Components Relationship..................................... 4-2 4.3 BASEstar Open Environment Components............. 4-2 4.3.1 Nodes ......................................... 4-3 4.3.2 PODB Nodes .................................... 4-4 4.3.3 Managing the PODB on an ORACLE Database ....... 4-5 4.3.4 Realms ........................................ 4-5 4.3.5 Sample Environment Configuration .............. 4-8 iv 5 Environment Management Procedures 5.1 Setup Procedures................................. 5-2 5.1.1 Setting Up a Node ............................. 5-2 5.1.2 Setting Up a Realm ............................ 5-2 5.1.2.1 Setting Up a Realm on a Node................ 5-3 5.1.2.2 Setting Up the Realm Database on the PODB Node........................................ 5-3 5.1.3 Setting Up the Sample Environment ............. 5-3 5.2 Startup Procedures............................... 5-5 5.2.1 Starting Up a Node ............................ 5-5 5.2.2 Starting Up a Realm ........................... 5-5 5.2.2.1 Starting Up a Realm on a Node............... 5-5 5.2.2.2 Starting Up the Database Server for a Realm on the PODB Node............................ 5-5 5.2.3 Starting Up the Sample Environment ............ 5-6 5.3 Shutdown Procedures.............................. 5-8 5.3.1 Shutting Down a Realm ......................... 5-8 5.3.1.1 Shutting Down the Database Server for a Realm on the PODB Node...................... 5-8 5.3.1.2 Shutting Down a Realm on a Node............. 5-8 5.3.2 Shutting Down a Node .......................... 5-9 5.3.3 Shutting Down the Sample Environment .......... 5-10 5.4 Unset Procedures................................. 5-12 5.4.1 Unsetting a Realm ............................. 5-12 5.4.1.1 Unsetting a Realm from a Node............... 5-12 5.4.1.2 Unsetting a Realm Database on the PODB Node........................................ 5-12 5.4.2 Unsetting a Node .............................. 5-12 5.4.3 Unsetting the Sample Environment .............. 5-13 5.5 Monitoring BASEstar Open......................... 5-14 6 Environment Management Command Reference 6.1 Executing Environment Commands................... 6-1 6.1.1 Requirements and Constraints .................. 6-1 6.1.1.1 Users and Commands.......................... 6-1 6.1.1.2 Issuing a Command........................... 6-3 v 6.2 Privileges Needed to Run Environment Management Procedures....................................... 6-4 bstr_env_show.................................... 6-5 bstr_node_setup.................................. 6-11 bstr_node_shut................................... 6-20 bstr_node_start.................................. 6-22 bstr_node_unset.................................. 6-24 bstr_realm_check_env............................. 6-26 bstr_realm_setup_db.............................. 6-29 bstr_realm_setup_node............................ 6-31 bstr_realm_shut_db............................... 6-33 bstr_realm_shut_node............................. 6-34 bstr_realm_start_db.............................. 6-36 bstr_realm_start_node............................ 6-37 bstr_realm_unset_db.............................. 6-39 bstr_realm_unset_node............................ 6-41 bstr_run......................................... 6-43 7 BASEstar Open Environment Monitor 7.1 Introduction..................................... 7-1 7.2 Running the BASEstar Open Environment Monitor.... 7-3 7.3 General Characteristics.......................... 7-3 7.4 Views............................................ 7-4 7.4.1 Active Realm View ............................. 7-4 7.4.2 Active Node View .............................. 7-7 8 BASEstar Open-Supplied Servers 8.1 Servers, Activities and Owned Resources.......... 8-3 8.1.1 Snapshots ..................................... 8-3 8.1.2 Logged Information ............................ 8-4 8.2 Global Object Services........................... 8-5 8.3 Application Management Services.................. 8-7 8.3.1 Environment Variables - Inheritance and Usage.......................................... 8-7 8.4 Event Services................................... 8-9 8.4.1 Using Application Management Services to Manage an Event Services Server....................... 8-9 8.4.2 Starting Up and Shutting Down an Event Services Server from the Command Interpreter............ 8-9 vi 8.5 Packet Services.................................. 8-12 8.5.1 Using Application Management Services to Manage a Packet Services Server....................... 8-12 8.5.2 Starting Up and Shutting Down a Packet Services Server from the Command Interpreter............ 8-12 8.6 Data Services.................................... 8-15 8.6.1 Environmental Variables ....................... 8-15 8.6.2 Using Application Management Services to Manage a Data Services Server......................... 8-16 8.6.3 Starting Up and Shutting Down a Data Services Server from the Command Interpreter............ 8-17 8.7 Device Services.................................. 8-19 8.7.1 Global Variables .............................. 8-19 8.7.1.1 Specifying the Calling VMD.................. 8-19 8.7.1.2 Specifying the Connection Retry Timeout to a VMD......................................... 8-20 8.7.2 Using Application Management Services to Manage a Device Services Server....................... 8-21 8.7.3 Starting Up and Shutting Down a Device Services Server from the Command Interpreter............ 8-21 8.8 Combined Data & Device Services.................. 8-23 8.8.1 Environmental Variables ....................... 8-23 8.8.2 Using the Data & Device Services to Support Passive Connections............................ 8-25 8.9 PC Communication Servers......................... 8-26 9 Application Management Services Monitor 9.1 Introduction..................................... 9-1 9.2 Running Application Management Services Monitor.. 9-2 9.3 General Characteristics.......................... 9-3 9.4 Views............................................ 9-5 9.4.1 Actor View .................................... 9-6 9.4.2 Activity View ................................. 9-9 9.4.3 Program View .................................. 9-11 9.4.4 Process View .................................. 9-13 9.4.5 Node View ..................................... 9-15 vii 10 Log Services Features 10.1 Saving Copies of Log Files....................... 10-1 10.1.1 Log File Location ............................. 10-2 10.1.2 Purging Log Files ............................. 10-2 10.2 Log File Record Format........................... 10-3 10.2.1 Displaying Log Files .......................... 10-8 10.2.1.1 Displaying a Save Copy...................... 10-9 10.2.1.2 Displaying a Working Copy................... 10-9 10.3 Log Services Server Activities................... 10-9 11 Log Services Command Reference DISPLAY LOG...................................... 11-2 OPEN LOG......................................... 11-4 A Files Installed by BASEstar Open Server A.1 Digital UNIX Systems............................. A-1 A.1.1 Directories Installed by the BSTBASE300 Subset......................................... A-1 A.1.2 Files Installed by the BSTBASE300 Subset ...... A-2 A.1.3 Files Installed by the DOUBASE300 Subset ...... A-12 A.1.4 Files Installed by the DOUMAN300 Subset ....... A-15 B BASEstar Open Global Variables B.1 Global Variable List............................. B-1 B.2 Installation-specific Global Variables........... B-9 B.2.1 Setting the Values of Global Variables ........ B-10 B.3 BSTR_REALM Global Variable....................... B-10 B.4 Global Variables for Server Activation........... B-10 B.5 Application Management Services Global Variables........................................ B-11 C Environment and Parameter Files C.1 General Record Format............................ C-1 C.2 Format of the File for the Node environment Attribute........................................ C-3 C.3 Format of the File for the Program parameters Attribute........................................ C-4 C.3.1 File Format ................................... C-4 viii D Environment Component Processes D.1 Processes........................................ D-2 E Managing Snapshot Files in a Distributed Environment E.1 Using Configuration Management Commands in a Multi-node Environment........................... E-1 E.2 Snapshot File Location........................... E-2 E.3 The BSTR_DBACCESS_KEY Global Variable............ E-3 E.4 Making Snapshot Files Accessible................. E-3 E.4.1 Mounting Snapshot Directories with NFS ........ E-3 E.4.2 Copying Snapshot Files Using a File Transfer .. E-4 Index Examples 10-1 Node Log File Example ......................... 10-4 10-2 Realm Log File Example ........................ 10-7 Figures 4-1 Sample BASEstar Open Environment .............. 4-9 7-1 Active Realm View ............................. 7-4 7-2 Active Node View .............................. 7-7 9-1 Actor View (default) .......................... 9-2 9-2 Cursor Mode ................................... 9-5 9-3 Actor View with Actor Attributes .............. 9-6 9-4 Actor View with Activity Attributes ........... 9-8 9-5 Activity View ................................. 9-10 9-6 Program View .................................. 9-12 9-7 Process View .................................. 9-14 9-8 Node View ..................................... 9-15 ix Tables 1 Conventions Used in BASEstar Open ............. xii 1-1 BASEstar Open Server Subsets .................. 1-3 1-2 Required Subsets .............................. 1-5 1-3 Worksheet for Disk Space Requirements (Kilobytes).................................... 1-7 6-1 Relationship Between Environment Management Commands and Users............................. 6-2 6-2 Environment Management Privileges ............. 6-4 8-1 Environment Variables - Validity and Usage .... 8-8 8-2 Data Management-Environmental Variables ....... 8-15 8-3 Device Management-Environmental Variables ..... 8-20 8-4 Data and Device Management-Environmental Variables...................................... 8-23 10-1 Log Services CLI Commands ..................... 10-2 10-2 Log File Component Identifier ................. 10-3 A-1 Directories Installed by the BSTBASE300 Subset......................................... A-1 B-1 BASEstar Open Global Variables ................ B-1 C-1 Valid Values of the File for the Node environment Attribute.......................... C-3 C-2 Valid Values of the File for the Program parameters Attribute........................... C-5 D-1 Processes ..................................... D-3 x _________________________________________________________________ Preface This guide describes how to install the BASEstar Open software on Digital and HP processors running the UNIX operating system. Keep this document with your distribution kit. You may need it to install maintenance updates or to reinstall BASEstar Open Server. Multiplatform Applicability The information in this manual is only applicable to BASEstar Open server nodes on UNIX systems. Intended Audience This guide is addressed to system managers responsible for installing and setting up BASEstar Open Server software on UNIX systems. Prerequisites Any users required to install and manage the BASEstar Open environment must know how to manage a UNIX system. A basic knowledge of BASEstar Open features is also recommended. Structure of this Document This manual is organized as follows: o Chapter 1 describes the Digital UNIX operating system, the hardware/software requirements for installation, and the related procedures that you must complete before installing BASEstar Open Server on a Digital UNIX system. ix o Chapter 2 describes how to install BASEstar Open Server on a Digital UNIX system. o Chapter 3 describes how to install BASEstar CIMfast on a Digital UNIX system. o Chapter 4 provides an overview of environment management issues. o Chapter 5 describes the procedures that allow you to set up, start up and shut down the components of your BASEstar Open Server environment. o Chapter 6 contains reference information for the above procedures, including the necessary prerequisites and privileges. o Chapter 7 describes the BASEstar Open Environment Monitor, an interactive tool that enables you to monitor the BASEstar Open environment at run-time. o Chapter 8 explains how to start up, shut down and manage BASEstar Open-supplied servers. o Chapter 9 describes the Application Management Services Monitor, an interactive tool that enables you to monitor Application Management Services objects. o Chapter 10 describes how Node-specific log services collect information from the environment components. o Chapter 11 contains reference information for the log services commands. o Appendix A describes the files and directories on your system after installation. o Appendix B lists and describes the BASEstar Open global variables. o Appendix C describes the format and contents of: - The environment file, as specified in the environment attribute of a Node object - The parameter file, as specified in the parameters attribute of a Program object o Appendix D lists the platform-dependent processes that implement each BASEstar Open environment component. x o Appendix E provides information about managing snapshot files in a multi-node environment. This appendix is relevant to Digital UNIX systems only. BASEstar Open Documentation Set This manual describes a software component or aspects of the BASEstar Open family of products. The complete set of documents relating to the BASEstar Open family is as follows: o BASEstar Open: - BASEstar Open Introduction - BASEstar Open Reference Guide - BASEstar Open Command Language Interface - BASEstar Open Application Programming Interface - BASEstar Open Messages - Platform-specific installation and management guides - BASEstar Open Guide to DCM-Modeled Device Connectivity (for supported platforms) o BASEstar CIMfast (for supported platforms): - BASEstar CIMfast User's Guide - BASEstar CIMfast Programmer's Reference Guide - BASEstar CIMfast Guide to DECmessageQ Support - BASEstar CIMfast Guide to SQL Support o DEComni API: - DEComni API User Guide - DEComni API Guide to Using Omni Directory Services (for supported platforms) - DEComni API Guide to Using OmniView (for supported platforms) o Device Access Software documentation - Specific manuals for each supported device xi Conventions Table 1 lists the conventions used in the BASEstar Open documentation set. Table_1_Conventions_Used_in_BASEstar_Open________________________ % The default user prompt is your system name followed by a right angle bracket (>). In the BASEstar Open docset, a percent sign (%) is used to represent this prompt. / Indicates that you must hold down the Ctrl key while you press another key. In examples, a key name enclosed in a box indicates that you press a key on the keyboard. (In text, a key name is not enclosed in a box.) . A vertical ellipsis indicates the omission of . items from a code example or sample command; . the items are omitted because they are not important to the topic being discussed. . . . A horizontal ellipsis in format descriptions or in examples indicates one of the following possibilities: o Additional optional arguments in a statement have been omitted. o The preceding item or items can be repeated one or more times. o Additional parameters, values, or other information can be entered. [] In format descriptions, brackets indicate optional elements; you can select none, one, several, or all of the choices. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file specification, or in the syntax of a substring specification in an assignment statement.) (continued on next page) xii Table_1_(Cont.)_Conventions_Used_in_BASEstar_Open________________ ( ) In format descriptions, parentheses indicate that, if you choose more than one option, you must enclose the choices in parentheses. boldface text Boldface text represents one of the following cases: o user input o the introduction of a new term o the status values true or false italic type Indicates titles of manuals, variables, arguments, data structures, fields, callable functions, operands, and utilities. Italic text also represents information that can vary in system messages (for example, Internal error number), command lines (for example, /PRODUCER=name), and command operands in text. code type Indicates information that is part of the code for a program or application. numbers Unless otherwise noted, all numbers in the text are assumed to be decimal. Nondecimal radixes- binary, octal, or hexadecimal-are explicitly indicated. UPPERCASE TEXT Uppercase text indicates a command, the name of a file, the name of a file protection code, the abbreviation for a system privilege, the name of a field, or the value of an attribute where attributes are chosen from a list. "point_a + Literal string. Using quotation marks is point_b" optional unless there is a space, slash (/), or parenthesis in the string. (continued on next page) xiii Table_1_(Cont.)_Conventions_Used_in_BASEstar_Open________________ BASEstar Open Valid characters for the names of BASEstar Open names objects are the alphanumeric characters (A-Z) and (0-9), the underscore (_), the dollar sign ($), and the following multinational __________________characters:_ÅÀÁÂÃÄÇÈÉÊËÌÍÎÏÒÓÔÕÖÙÚÛÜÆÑ@Øß._____ xiv Installation Section - Digital UNIX _________________________________________________________________ 1 _________________________________________________________________ Preparing to Install BASEstar Open Server on a Digital UNIX System This chapter provides the necessary information to make your installation run smoothly. Before attempting the installation procedures in Chapter 2, you should complete the pre-installation requirements outlined here. 1.1 Release Notes Your documentation includes the BASEstar Open for UNIX Release Notes. Read this document before installing and using the product. The release notes may contain information about changes to the application. After you install the BASEstar Open Server software, you can also access the online release notes in the form of an ASCII text file by entering the following command: # more /usr/opt/bstbase300/doc/relnotes.txt (Digital UNIX) Your documentation may also include the BASEstar Open Release Notes Addendum or Read Before Installing letter. This letter provides information that is important for you to know before installing Digital UNIX, BASEstar Open or BASEstar CIMfast, and that may not be included either in management guides or primary release notes documents. If the Release Notes Addendum or Read Before Installing letter is listed on your BOM (Bill of Material), please check to see whether it contains information about BASEstar Open or BASEstar CIMfast. 1-1 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.2 License Registration 1.2 License Registration BASEstar Open Server includes support for the Digital UNIX License Management Facility (LMF). A License Product Authorization Key (License PAK) must be registered in the License Database (LDB) in order to use BASEstar Open Server on a newly-licensed node. The License PAK may be shipped along with the kit if you ordered the license and media together; otherwise, it is shipped separately to a location based on your license order. If you are installing BASEstar Open Server as an update on a node already licensed for this software, you have already completed the License PAK registration requirements. If you are installing pre-requisite or optional software along with BASEstar Open Server, review the PAK status and install the PAKs for any pre-requisite or optional software before you install BASEstar Open Server. To register a license under the Digital UNIX system, follow these steps before installing BASEstar Open Server: 1. Log in as superuser. 2. At the superuser prompt, edit an empty PAK template with the lmf register command and include all the information on your License PAK as follows: # lmf register Refer to the current BASEstar Open Server Version 3.0 Software Product Description (SPD) for complete information on possible licenses and associated PAKs. After you register your license, use the following lmf reset command to copy the license details from the License Database (LDB) to the kernel cache: # lmf reset For complete information on using the Digital UNIX License Management Facility, see the UNIX Guide to Software Licensing or the lmf(8) reference page. 1-2 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.3 Checking the Media Software Distribution Kit 1.3 Checking the Media Software Distribution Kit Use the Bill of Materials (BOM) to check the contents of your BASEstar Open Server software distribution kit. The kit includes this installation guide and the CDROM optical disk for Alpha systems. Your distribution kit may also include a letter titled BASEstar Open Release Notes Addendum or Read Before Installing BASEstar Open. This letter provides information that is important for you to know before installing the product and may not be included in this installation guide or release notes. If you have this letter, please read it now. 1.4 BASEstar Open Server Subsets Table 1-1 lists and describes the subsets contained in the BASEstar Open Server software kit, together with their installation requirements. Table_1-1_BASEstar_Open_Server_Subsets_____________________ Subset_Name_________Description____________________________ BSTBASE300 BASEstar Open Server Version 3.0 base system. You must always install this subset. DOUBASE300 DEComni Application Programming Interface. You need only install this subset if the Device Services MMS-modeled device connectivity is used. DOUMAN300 Manual pages for the DEComni Application Programming Interface. You can install this subset as desired (usually after installation of the DOUBASE300 subset). CIMfast (continued on next page) 1-3 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.4 BASEstar Open Server Subsets Table_1-1_(Cont.)_BASEstar_Open_Server_Subsets_____________ Subset_Name_________Description____________________________ BCFASE220 BASEstar CIMfast for UNIX base components BCFMAN220 BASEstar CIMfast for UNIX online documentation BCFDEV220 BASEstar CIMfast for UNIX development option BCFDMQ220 BASEstar CIMfast for UNIX DECmessageQ ____________________support________________________________ 1.5 Installation Procedure Requirements Installing BASEstar Open Server and running the Installation Verification Procedure (IVP) on your Digital UNIX system takes approximately 5 to 20 minutes. 1.5.1 Checking Login Privileges You must be able to log in as superuser on the system where you are installing BASEstar Open Server. Only if you are logged in as superuser do you have sufficient privileges to install the BASEstar Open Server software. 1.5.2 Hardware Requirements To perform the installation, you require a minimum hardware configuration as spelled out in your BASEstar Open Server Software Product Description (SPD). The minimum hardware requirements are as follows: o A supported Alpha AXP processor (see the BASEstar Open Server Version 3.0 Software Product Description (SPD) for details) o A terminal o Sufficient free disk space (as described in Section 1.5.4) Check the SPD to see if there are further hardware requirements that apply to your particular application. 1-4 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.5 Installation Procedure Requirements 1.5.3 Software Requirements BASEstar Open Server Version 3.0 requires UNIX Version 3.0B or higher. Future BASEstar Open Server releases may require higher versions of the operating system, as described in the online release notes or the Read Before Installing or Using Letter. The Software Product Description contains a complete list of pre-requisite and optional software and their required version numbers. If you are installing BASEstar Open Server on a system that is to perform the role of a PODB node, you must also install and start up the ORACLE 7 database, using the RDBMS, TPO and SQL*Plus options. You must load the subsets of the various software products listed onto the system where you wish to install BASEstar Open Server: Table_1-2_Required_Subsets_________________________________ Subset_Name_________Comment________________________________ OSFBASE350 Always required OSFPGMR350 Always required OSFCLINET OSFDCMT350 Required for installing the online ____________________reference_pages_only___________________ To check whether the subsets are loaded, do the following: 1. Log in to the system where you wish to install BASEstar Open Server. 2. Enter the following commands: # /usr/sbin/setld -i | grep OSFBASE305 # /usr/sbin/setld -i | grep OSFPGMR305 # /usr/sbin/setld -i | grep OSFDCMT305 Check the displayed rows for the name of the relevant subset and any patches. The word "installed" appears in a row after the subset identifier when a subset is loaded. If the word "installed" does not appear (the second column in a row is blank), the subset or patch is not loaded. In this case, you must load the missing 1-5 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.5 Installation Procedure Requirements Digital UNIX software before installing BASEstar Open Server. 1.5.4 Determining Disk Space Requirements Table 1-3 lists the disk space requirements for loading BASEstar Open Server software subsets. They specify disk space requirements by file system for the convenience of those performing installations on systems where these file systems are mount points for different disk partitions. 1-6 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.5 Installation Procedure Requirements Table_1-3_Worksheet_for_Disk_Space_Requirements_(Kilobytes)[1]___ /usr Subset /var Subset_Title_______________Name________/___________/usr/opt____/opt BASEstar Open BSTBASE300 0 70,000 1,000 DEComni DOUBASE300 4,340 36,000 160 DEComni Reference Pages DOUMAN300 0 140 80 _________________________________________________________________ ________________________BASEstar_CIMfast_________________________ BASEstar CIMfast for BCFASE220 0 4000 0 UNIX Base Components BASEstar CIMfast BCFMAN220 0 10 0 for UNIX Online Documentation BASEstar CIMfast for BCFDEV220 0 3800 0 UNIX Development Option BASEstar CIMfast for BCFDMQ220 0 110 0 UNIX DECmessageQ Support BASEstar CIMfast for BCFSQLORA220[1] UNIX ORACLE SQL Support _________________________________________________________________ Totals:________________________________4,340_______114,060_____1,240 Using these tables, calculate the total values for the subsets that you plan to load in each system. Compare the space required for subsets with the free space currently on the disks where BASEstar Open Server files will reside. ____________________ [1] If you are using the ORACLE database, BASEstar Open checks that there are 50Mb of disk space in the /usr/tmp directory before running the IVP (see Section 2.3.1). 1-7 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.5 Installation Procedure Requirements 1.5.5 Increasing the Available Disk Space for BASEstar Open Server Installation The BASEstar Open Server installation procedure creates the following directories and loads files into subordinate directories: /usr/opt/bstbase300 /usr/var/opt/bstbase300 If the bstbase300 directory node in the previous paths does not exist, the installation procedure creates it. If the bstbase300 node in the previous paths does exist, the installation procedure uses it. If you find that there is insufficient disk space for the BASEstar Open Server subsets, and know that you have additional space on alternative disks or disk partitions for your system, ask the system manager to take the necessary actions. 1.6 Backing Up Your System Disk Digital recommends that you back up your system disk before installing any software. For details of how to perform a system disk backup, refer to your Digital UNIX documentation. 1.7 Stopping the Installation You can stop the installation procedure any time by using /. However, files created up to this point are not deleted automatically. You must delete these files interactively. Appendix A lists the files and directories created during the installation procedure. 1.8 Error Recovery If errors occur during the installation, the system displays failure messages. If the installation fails due to insufficient disk space, a message appears. For example, if the disk space lack is detected while installing the BSTBASE300, the following message is displayed: There is not enough file system space for subset BSTBASE300 BASEstar Open (BSTBASE300) will not be loaded. 1-8 Preparing to Install BASEstar Open Server on a Digital UNIX System 1.8 Error Recovery Errors may occur during the installation if: o The operating system version is incorrect o The pre-requisite software version is incorrect o The system parameter values for successful installation are insufficient. For descriptions of error messages generated by these conditions, see the Digital UNIX documentation on system messages, recovery procedures, and Digital UNIX software installation. For information on system software requirements, see Section 1.5.3. If an error occurs while using BASEstar Open Server and you believe the error is caused by a problem with the product, take the appropriate action as described in Section 2.4. 1-9 2 _________________________________________________________________ Installing BASEstar Open Server on a Digital UNIX System This chapter describes how to: o Install BASEstar Open Server on a Digital UNIX system o Run the Installation Verification Procedure (IVP) o Remove BASEstar Open Server from a Digital UNIX system Before starting the installation, read Chapter 1, which describes general options and requirements for installing the product. This installation procedure allows you to install BASEstar Open Server locally. In a local (node-specific) installation, the system on which you install the product uses its own disks to run it. The installation procedure loads BASEstar Open Server files onto the disks that belong to the system where you perform the installation. When you run BASEstar Open Server, its executable files are mapped into memory on the same system. 2.1 Installing CD-ROM Consolidated Distribution Media Start the installation procedure as follows: 1. Mount the media on the appropriate disk drive. 2. Log in as superuser (login name root) to the system where you are installing BASEstar Open Server. 3. Make sure that you are at the root (/) directory by entering the following command: # cd / 4. Specify the /mnt directory to be the mount point for the distribution file system on the drive. If your drive is rz4, enter the following command: # mount -dr /dev/rz4c /mnt 2-1 Installing BASEstar Open Server on a Digital UNIX System 2.1 Installing CD-ROM Consolidated Distribution Media 5. Enter a setld command that specifies the load function (-l) and identifies the directory in the mounted file system where BASEstar Open Server subsets are located. For example, if the directory location for these subsets is /mnt/BSTBASE300, enter the following command: # setld -l /mnt/BSTBASE300 2.2 Responding to Installation Procedure Prompts This section explains the installation procedure prompts. 2.2.1 Selecting Subsets After you enter the setld command for local (node-specific) installations, the installation procedure displays the names of the BASEstar Open Server subsets and asks you to specify the subsets that you want to load: Copyright (C) Digital Equipment Corporation. 1996. All Rights Reserved. Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of DFARS 252.227-7013, or in FAR 52.227-19, or in FAR 52.227-14 Alt. III, as applicable. This software is proprietary to and embodies the confidential technology of Digital Equipment Corporation. Possession, use, or copying of this software and media is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. The subsets listed below are optional: There may be more optional subsets than can be presented on a single screen. If this is the case, you can choose subsets screen by screen or all at once on the last screen. All of the choices you make will be collected for your confirmation before any subsets are installed. 2-2 Installing BASEstar Open Server on a Digital UNIX System 2.2 Responding to Installation Procedure Prompts 1 BASEstar Open Server V3.0 2) BASEstar Open V3.0 Reference Pages 3) CIMfast Base Components 4) CIMfast DECmessageQ Support 5) CIMfast Development Option 6) CIMfast On-line Manual Pages 7) CIMfast Oracle SQL Support 8) DASware - Common Run-Time Environment 9) DASware - Services for OSI 10) DASware - Services for RS-232 11) DASware - Services for TCP/IP 12) DASware - Services for X25 Or you may choose one of the following options: 13) ALL of the above 14) CANCEL selections and redisplay menus 15) EXIT without installing any subsets Enter your choices or press RETURN to redisplay menus. ) Choices (for example, 1 2 4-6): 1 2 Choices (for example, 1 2 4-6):1 2 If you specify more than one number at the prompt, separate each number with a space, not a comma. Next, the script lets you verify your choice. For example, if you enter 5 in response to the previous prompt, you will see the following display: You are installing the following optional subsets: BASEstar Open Server V3.0 BASEstar Open V3.0 Reference Pages Is this correct? (y/n): y If the displayed subsets are not the ones you intended to choose, enter n. In this case, the subset selection menu is again displayed, and you can correct your choice of optional subsets. If the displayed subsets are those you want to load, enter y. 2-3 Installing BASEstar Open Server on a Digital UNIX System 2.2 Responding to Installation Procedure Prompts 2.2.2 Monitoring Displays During the Subset Loading Process The procedure displays a message that the installation is starting: Checking file system space required to install selected subsets: File system space checked OK. Installation procedure for: The installation procedure continues. If, during the course of the installation, you encounter errors from the setld utility, see the Diagnostics section of the setld(8) reference page for an explanation of the error and the appropriate action to take. If the verification process fails, consult the /var/adm /smlogs/fverify.log file for information that may help you diagnose the problem. The final step of the installation procedure is signalled by the following prompt: To start up BASEstar Open Server V3.0 on each system bootstrap, you should create a link in the /sbin/rc3.d directory to the file /sbin/init.d/bstbaseboot. Do you want to create it now? (y/n) [y]: If you answer y, the installation procedure creates the bstbaseboot file in the /var/optbstbase300/etc directory. BASEstar Open Server starts up the BASEstar Open Node services by executing bstr_node_start during the normal bootstrap procedure. To stop BASEstar Open, it executes bstr_node_shut during the system shutdown procedure. 2.2.3 Running the IVP After the message that notifies you that BASEstar Open Server has been installed successfully, the procedure displays the following prompt which allows you to start the IVP: Do you want to run the BASEstar IVP now ? [yes] 2-4 Installing BASEstar Open Server on a Digital UNIX System 2.2 Responding to Installation Procedure Prompts It is recommended that you run the IVP to verify the installation. You can either run it during installation by answering yes to the above question, or later, as explained in Section 2.3. 2.2.4 Setting Up and Starting the BASEstar Open Server Environment After installing BASEstar Open Server, you must execute a series of procedures which set up and start Nodes and Realms. To make this task easier, the installation procedure displays the following prompts which allow you to set up and start the BASEstar Open Server environment: To configure this node, you should execute the script bstr_node_setup (/usr/var/opt/bstbase300/etc/bstr_node_setup). Do you want to execute it now? (y/n) [y]: If you answer y, the installation procedure sets up BASEstar Open on the local node by executing the bstr_ node_setup procedure. To start up BASEstar Open Server V3.0 on this node, you should execute the script (/usr/var/opt/bstbase300/etc/bstr_node_start). Do you want to execute it now? (y/n) [y]: If you answer y, the installation procedure starts up BASEstar Open on the local node by executing the bstr_ node_start procedure. For a full explanation of the bstr_ node_setup and bstr_node_start procedures, refer to Part II of this guide. 2.3 The Installation Verification Procedure Once you have completed BASEstar Open installation and any additional post-installation operations, it is advisable to run the Installation Verification Procedure (IVP) independently to verify that the software is available on your system. In order to verify the installation, the BASEstar Open Server IVP: 1. Checks that: - All kit files and directories are present and correct 2-5 Installing BASEstar Open Server on a Digital UNIX System 2.3 The Installation Verification Procedure - A valid license is correctly registered - The BASEstar Open Server node on which you are operating has been set up and started. If this is not the case, it performs both these operations. 2. Sets up and starts the BSTR_IVP Realm on the Node on which it is executed 3. Loads the appropriate Application Management Services configuration for the BSTR_IVP Realm. 4. It performs the following operations on the BSTR_IVP Realm: - Starts Data Services and Event Services servers - Creates objects in the Domains managed by the above servers - Shuts down the Data Services and Event Services servers. 5. If it is necessary to verify the PODB capabilities (see Section 2.3.1), the IVP performs the following operations: - Creates the BSTR_IVP/BSTR_IVP ORACLE login/password for the BSTR_IVP Realm - Starts the Database Services server for the BSTR_IVP Realm - Creates the object definitions for the BSTR_REALM Realm in the PODB - Generates a snapshot configuration and tries to start up the Data & Device Services server and the Event Services server, before performing operations on the object - Shuts down the Data & Device Services server and the Event Services server - Shuts down the Database Services server and deletes the BSTR_IVP/BSTR_IVP ORACLE login/passwords. 6. Shuts down the node in an orderly fashion (if started by the IVP). 2-6 Installing BASEstar Open Server on a Digital UNIX System 2.3 The Installation Verification Procedure 7. Resets the node in an orderly fashion (if set up by the IVP). The IVP procedure execution takes about 5 minutes (if your system is not a PODB Node) or 20 minutes (if your system is a PODB Node). 2.3.1 Prerequisites and Constraints Execution of the IVP is subject to the following prerequisites and constraints: o A valid BASEstar Open Server license has been registered o The account from which you run the IVP must have superuser status. o If you wish to verify the PODB feature on the node, ensure that the selected database has been started up successfully before running the IVP. For further details, refer to the product-specific documentation. o If you run the IVP procedure before setting up the node, BASEstar Open Server checks that there are 50Mb of disk space in the /usr/tmp directory. If this space is not available, the IVP does not verify the capabilities of the PODB database. o The resources used are as follows: - The IVP automatically creates (and deletes after use) the BSTR_IVP Realm and, if verification of the PODB capabilities must also be performed, the BSTR_ IVP/BSTR_IVP ORACLE login/password. Therefore, you cannot create a Realm and an ORACLE login/password with these names. - The IVP uses the UDP port numbers from 14073 to 14078. o Note that, during execution, the IVP modifies and restores the /etc/services system file. 2-7 Installing BASEstar Open Server on a Digital UNIX System 2.3 The Installation Verification Procedure 2.3.2 Running the Installation Verification Procedure After installing BASEstar Open Server, it is recommended that you run the Installation Verification Procedure (IVP) independently to verify that the software is correctly installed and ready to use on your system. You might also want to run the IVP after a system failure to be sure that users can access BASEstar Open Server. To run the IVP, enter the following command: # setld -v BSTBASE300 Each time you run the IVP, it creates the /tmp/bstr_ivp_.log and /tmp/ivp_bstrlogfiles log files. The /tmp/ivp_bstrlogfiles file contains a copy of the Node and Realm BASEstar Open Server log files generated during IVP execution (see Part II for details). 2.4 Reporting Errors If an error occurs while you are using BASEstar Open Server, and you believe the error is caused by a problem with the product, take the following steps: o If you have a basic or DECsupport Software Agreement, call your Customer Support Center (CSC). The CSC provides telephone support for high-level advisory and remedial assistance. o If you have a Self-Maintenance Software Agreement, submit a Software Performance Report (SPR). o If you purchased BASEstar Open Server less than 90 days previously, and you think the problem was caused by a software error, you can submit an SPR. If you find an error in the BASEstar Open Server documentation, fill out and submit one of the Reader's Comments forms at the back of the document containing the error. Specify the section and page number where the error occurred. If you submit an SPR, please take the following steps: 1. Describe as accurately as possible the circumstances and state of the system when the problem occurred. Include a description and version number of the BASEstar Open 2-8 Installing BASEstar Open Server on a Digital UNIX System 2.4 Reporting Errors Server software being used. Demonstrate the problem with specific examples. 2. Reduce the problem to as small a size as possible. 3. Remember to include listings of any command files, include files, or relevant data files, and so forth. 4. Provide a listing of the program. 5. If the program is longer than 50 lines, submit a copy of it on machine-readable media (floppy diskette or magnetic tape). If necessary, submit a copy of the program library used to build the application. 6. Report only one problem per SPR. This will facilitate a faster response. 7. Mail the SPR package to Digital. Experience shows that many SPRs do not contain enough information to duplicate or identify the problem. Concise, complete information helps Digital give accurate and timely service to software problems. 2.5 Deleting BASEstar Open Server From Your System To remove a version of BASEstar Open Server from your system, delete each subset that you previously installed. To delete subsets, follow these steps: 1. Log into a superuser account(login name root). 2. Make sure you are at the root directory (/) by entering the following command: # cd / 3. Enter the following setld commands: # setld -i | grep BSTBASE300 # setld -i | grep DOUBASE300 # setld -i | grep DOUMAN300 4. Look for the word "installed" in the listing produced, then delete the installed subsets. For example: # setld -d BSTBASE300 # setld -d DOUBASE300 # setld -d DOUMAN300 2-9 Installing BASEstar Open Server on a Digital UNIX System 2.6 Displaying Documentation from CD-ROM 2.6 Displaying Documentation from CD-ROM The BASEstar Open documentation is located on the UNIX Layered Products Online Documentation CD-ROM in Bookreader (.DECW$BOOK) file format. You can display the Bookreader files on your workstation using the DECwindows Bookreader application. For information on accessing and displaying these files, refer to the Digital UNIX Layered Products Disc User's Guide. 2.6.1 Using the Startup Files Created During the Installation BASEstar CIMfast users must execute the BASEstar CIMfast setup file when logging on to the system. The command to use depends on the user's shell: o Sh or Sh5 shell # ./etc/bcf_setup.sh o C shell # source /etc/bcf_setup.csh 2-10 3 _________________________________________________________________ Installing BASEstar CIMfast This chapter describes how to install BASEstar CIMfast, an application development environment for creating real- time event-driven applications, on a Digital UNIX system. Before attempting to install BASEstar CIMfast, make sure that you have already installed BASEstar Open as described in Chapter 2. This installation procedure loads BASEstar CIMfast for UNIX onto the disks that belong to the system where you perform the installation. When you run BASEstar CIMfast, BASEstar Open maps its executable files into memory on the same system. You can install BASEstar CIMfast in a number of ways: o Locally o From tape o From disk o From CD-ROM 3.1 Starting the Installation Procedure 3.1.1 Using CD-ROM Consolidated Distribution Media Start the installation procedure as follows: 1. Mount the media on the appropriate disk drive. 2. Log in as superuser (login name root) to the system where you are installing BASEstar CIMfast. Make sure that BASEstar Open Server is up and running before you execute the BASEstar CIMfast IVP. 3-1 Installing BASEstar CIMfast 3.1 Starting the Installation Procedure 3. Enter the following command to ensure that you are at the root (/) directory: # cd / 4. Specify the /mnt directory as the mount point for the distribution file system on the drive. If your drive is rz4, enter the following command: # mount -r /dev/rz4l /mnt 5. Identify the directory in the mounted file system where BASEstar CIMfast subsets are located and enter a setld command, specifying the directory with the load (-l flag). For example, to load BASEstar CIMfast subsets onto a system, enter the following command: # # setld -l /mnt/your_mnt_point/BCF220 See Section 3.2 to continue the installation. 3.2 Responding to Installation Procedure Prompts This section describes the installation procedure prompts and displays. 3.2.1 Selecting Subsets When you enter the setld command, the installation procedure: o Displays the names of the BASEstar CIMfast for UNIX subsets o Asks you to specify the subsets that you want to load: *** Enter Subset Selections *** The subsets listed below are optional: 1 CIMfast Base Components 2) CIMfast Development Option 3) CIMfast On-line Manual Pages 4) CIMfast DECmessageQ Support 5) CIMfast SQL Oracle Support 6) All of the Above 7) None of the Above 8) Exit without installing subsets 3-2 Installing BASEstar CIMfast 3.2 Responding to Installation Procedure Prompts Enter your choice(s): If you specify more than one number at the prompt, separate each number with a space, not a comma. o Allows you to verify your choice. For example, if you enter 6 in response to the previous prompt, the following is displayed: You are installing the following subsets: CIMfast Base Components CIMfast Development Option CIMfast On-line Manual Pages CIMfast DECmessageQ Support CIMfast SQL Oracle Is this correct? (y/n): In response to the prompt, enter: o n, if the subsets displayed are not the ones you intend to choose. If this is the case, the procedure redisplays the subset selection menu so that you can correct your choice of optional subsets. o y, if the subsets displayed are the ones you want to load. 3.2.2 Monitoring Displays During the Subset Loading Process The procedure displays a message that the installation is starting. Refer to Section 3.3 for information regarding the postinstallation requirements specified in the final informational messages from the procedure. If you encounter errors from the setld utility during the course of the installation, see the Diagnostics section of the setld(8) reference page for an explanation of the error and the appropriate action to take. If the verification process fails, the information in the file /usr/var/adm /smlogs/fverify.log may help you to diagnose the problem. 3.3 Completing the Installation 3-3 Installing BASEstar CIMfast 3.3 Completing the Installation 3.3.1 Running the Installation Verification Procedure After installing BASEstar CIMfast, you must run the Installation Verification Procedure (IVP) independently to verify that the software is available on the system. To run the IVP for BCFDEV, make sure that BASEstar Open Server is up and running. To run the IVP after an installation, enter the following command: # setld -v BCFBASE220 If you installed the BASEstar CIMfast for UNIX Development Option, you can also run the IVP for this subset. The Development Option IVP builds the BASEstar CIMfast example programs. Make sure that you run this IVP from the root account, otherwise the IVP will not build the example programs, and the users will be unable to execute them. To run the Development Option, enter the following command: # setld -v BCFDEV220 It is also recommended that you run the IVP after a system failure to make sure that users can access BASEstar CIMfast. 3.3.2 Using the Startup Files Created During the Installation BASEstar CIMfast users must execute the BASEstar CIMfast setup file when logging on to the system. The command to use depends on the user's shell: o Sh or Sh5 shell # ./etc/bcf_setup.sh o C shell # source/etc/bcf_setup.csh 3-4 Environment Management Section _________________________________________________________________ 4 _________________________________________________________________ Introduction to Environment Management An application consists of a set of application components; that is, user-written programs and BASEstar Open-supplied servers running on a distributed system configuration, including various types of computers, plant devices and cables. To provide users with transparent access to BASEstar Open objects, regardless of their physical location in the distributed system, you must prepare your BASEstar Open environment. For example, you must set up and start up Nodes and Realms. 4.1 Environment Management Overview This section provides an overview of the BASEstar Open environment management operations. Setting Up BASEstar Open To set up BASEstar Open, you must set up Nodes and Realms. Setting up a Node involves creating the static resources (directories, files and environment-specific components) that enable a system of any supported platform to function as a BASEstar Open Node. Setting up a Realm involves creating directories and files that contain object definitions within a Realm. Starting Up BASEstar Open To make the BASEstar Open environment available to users, you must start up Nodes and Realms. Shutting Down BASEstar Open To make BASEstar Open unavailable to users you must shut down Nodes and Realms in an orderly fashion. 4-1 Introduction to Environment Management 4.1 Environment Management Overview Unsetting BASEstar Open To unset BASEstar Open you must delete Realm and Node directories and files, and the database containing the Realm object definitions. Monitoring BASEstar Open At any time you can know if the BASEstar Open environment has been set up and started up successfully on Nodes and Realms. For example, you can display the list of the Realms available (that is, started up) on a Node. 4.2 Environment and Application Components Relationship Once you have completed the setup and startup operations for the BASEstar Open environment, you can request the Application Management Services to start up, monitor, and shut down the application components (that is, user-written programs and BASEstar Open-supplied servers). When you shut down BASEstar Open, you must first shut down the application components and then the environment components. You can shut down the application components using, for example, the Application Management Services. The BASEstar Open Command Language Interface describes how to configure, start up and shut down the application components using Application Management Services features. Chapter 5 describes the procedures that you must use to set up, start up, shut down and unset the environment components. 4.3 BASEstar Open Environment Components The components of a BASEstar Open environment are: o Nodes o PODB Nodes o Realms In this context, Nodes and Realms are not considered as objects, but as a set of environment components that make Nodes and Realms available in the multi-node, multi- platform, distributed BASEstar Open environment. 4-2 Introduction to Environment Management 4.3 BASEstar Open Environment Components 4.3.1 Nodes A BASEstar Open Node is a computer of any of the supported platforms on which BASEstar Open has been installed and set up. To make a Node available in the BASEstar Open environment you must start up its components by executing the bstr_node_start command. The following are Node-specific components: o Log Services o Watchdog o Name Service Each of these components is described in the sections that follow. See also Appendix D for information about the processes that implement components on each platform. Log Services On each Node, the Log Services server collects log information from Node-specific environment components and from the environment components of the Realms that are started up on such Node. The Log Services server writes the collected information to the appropriate log files. See Chapter 10 and Chapter 11 for information about Log Services feature and functions, and about how users can display and manage log files. Watchdog The Watchdog component of a Node periodically checks for availability of other Nodes. If a Node is unavailable, the Watchdog notifies the relevant components. Name Service The Name Service component of a Node makes internal symbols and their values unique and globally available to BASEstar Open. The Name Service is made up of client and server parts: o A Name Service client process must be active on each Node o The Name Service server must be started up on one Node of the distributed BASEstar Open multi-node environment. 4-3 Introduction to Environment Management 4.3 BASEstar Open Environment Components The Name Service server is fundamental to the availability of the BASEstar Open environment. If the server fails, the BASEstar Open environment becomes unavailable. To avoid this, a redundancy mechanism is provided which is based on a primary and a secondary copy of the Name Service server. When the Nodes are started up, the primary copy is activated on the specified Node and becomes the current Name Service server. At the same time, the secondary copy is activated in stand-by mode on another Node. If the current Name Service server fails or becomes unavailable for any reason, BASEstar Open activates the secondary copy, which becomes the current one. The Node setup procedure is used to specify on which Nodes the primary and secondary copies are to be activated. 4.3.2 PODB Nodes When you set up the BASEstar Open environment, you can decide which BASEstar Open Nodes act as PODB Nodes (that is, contain the PODB object definitions). However, bear in mind the following considerations: o You can only designate ONE Node to act as the PODB Node for a given Realm o It is possible to designate a given Node as the PODB Node for different Realms. The example in Section 4.3.5 illustrates that NODE_DB has been set up as the PODB Node for both MY_REALM and TS_REALM. Alternatively, you could set up NODE_DB as the PODB Node for MY_REALM, and NODE1 (or NODE2) as the PODB Node for TS_REALM. BASEstar Open supports various databases for the storage of PODB object definitions. On UNIX Nodes, you can use an Oracle database. Refer to Section 4.3.3 for hints about managing the PODB on an ORACLE database. When you start up your environment, you must also start up the Database Services server on the PODB Node of each Realm that requires object definitions to be stored in the PODB. 4-4 Introduction to Environment Management 4.3 BASEstar Open Environment Components 4.3.3 Managing the PODB on an ORACLE Database Below is a series of hints about how to manage a PODB on an ORACLE database: o ORACLE_HOME environment variable Make sure that the ORACLE_HOME environment variable points to the login directory of the ORACLE account. o Modifying ORACLE resources If you create several databases for different Realms on the same Node, some ORACLE resources may be insufficient. If this is the case, run bstr_realm_setup_db: this command displays ORACLE error messages that indicate which resources you need to increase. To increase resources, follow these steps: 1. Edit the $ORACLE_HOME/dbs/init$ORACLE_SID.ora file 2. Shut down ORACLE processes 3. Restart ORACLE processes by supplying the name of the above file as a parameter file The bstr_node_setup command creates $ORACLE_HOME/dbs /init$ORACLE_SID.ora with default values. 4.3.4 Realms User-written application processes and BASEstar Open- supplied servers are the application components of each Realm. These components are managed directly by the end- users through the Application Management Services or from the command interpreter. Before starting up Realm application components, you must start up the Realm environment components on the appropriate Node(s). When you start up a Realm on a Node, BASEstar Open activates the following environment components: o Communication Service o Global Object Services server o Application Management Services server o Database Services server o PC Communication server 4-5 Introduction to Environment Management 4.3 BASEstar Open Environment Components BASEstar Open activates the per Node Realm-specific components when you execute the bstr_realm_start command. A brief description of these components is given below. Communication Service The Communication Service allows transparent communication between application and environment components of a Realm. This communication is independent of the number of Nodes on which the Realm has been started up. For example, the Communication Service features allow you to access a Data_Point (through an API or a CLI service request) without needing to know the physical location of the Data & Device Services server that makes the Data_Point available. Global Object Services Server Global Object Services servers make global objects available in a Realm. Global objects are those that already exist before servers that use them can be started up. For example, a Data & Device Services server must already find the associated Domain in the VODB, otherwise it could not create objects in the VODB. Global objects also include those objects that must be globally available in the Realm to all the other servers. For example, the same Datatype could be referred to by Event Services and Data & Device Services objects, and therefore it must be available in the Realm, regardless of whether any other server is available. A Global Object Services server is started up on each Node where a Realm is started up. This allows distributed management of the global objects; all the Global Object Services servers of a distributed Realm work together to make available to any user or to other servers all the same global objects independently of their location. Application Management Services Server When you start up a Realm on a given Node, the Application Management Services server is also activated and makes the Application Management Services objects and features available on that Node. This enables users at any Realm Node to request services such as executing, suspending, resuming and terminating Activities. 4-6 Introduction to Environment Management 4.3 BASEstar Open Environment Components As soon as you start up the Realm on other Nodes, an Application Management Services server is activated on each of them, thus allowing distributed management of the Realm application components. For example, you can execute an Activity on a Realm Node from any Node of the Realm. As another example, if a Realm Node fails, the Application Management Services servers running on the other Nodes of the Realm cooperate to restart the Realm application components on the Node(s) specified by the user in the configuration. To provide such dynamic and distributed services, the Application Management Services servers of a Realm continuously notify each other of their respective availability and operations in progress. PC Communication Server One PC Communication server is activated on a Node when a Realm is started up on that Node. BASEstar Open applications running on client Nodes can operate in transparent mode on the objects of a Realm through any PC Communication server active for that Realm. This is independent of the Realm Node on which the servers that make these objects available have been started. See the BASEstar Open Client Management Guide for details of how to install, configure and manage BASEstar Open Client on PC platforms. Database Services Server A Database Services server should be activated on the Realm PODB Node. A Database Services server must be started up only for Realms that require object definitions to be stored in the Permanent Object Database. The Database Services server is activated when the bstr_ realm_start_db command is executed. 4-7 Introduction to Environment Management 4.3 BASEstar Open Environment Components 4.3.5 Sample Environment Configuration Figure 4-1 gives an example of a BASEstar Open environment that consists of three systems interconnected through a LAN. To make this sample environment available, you must: 1. Set up NODE_DB, NODE1 and NODE2. In the example, NODE_DB acts as the PODB Node for both MY_REALM and TS_REALM. 2. Start up each Node. 3. Set up MY_REALM on each Node. 4. Set up TS_REALM on each Node. 5. Start up the environment components of MY_REALM on each Node where MY_REALM must be available (that is, on all the Nodes). 6. Do the same for TS_REALM, but on NODE_DB and NODE1 only. 7. On the PODB Node, start up a Database Services server for each Realm. In Figure 4-1, it is assumed that NODE_DB is a Digital UNIX system capable of acting as the PODB Node (ORACLE is the selected database). It is also assumed that NODE1 is a OpenVMS system and NODE2 is a Digital UNIX system. However, there are numerous alternatives to this configuration; for example, you could also have MS Windows client Nodes. 4-8 Introduction to Environment Management 4.3 BASEstar Open Environment Components Figure 4-1 Sample BASEstar Open Environment NODE_DB +-----------------------------+ | MY_REALM | | +-----------+-------+ | | | | | | PODB | | Realm- | DB | | +-----------------+ | | Specific | Server| | | | | | Environment | | | +------------+ | | | Components| | +--------| | my_realm | | | +-----------+-------+ | | +------------+ | | TS_REALM | | | | +-----------+-------+ | | +-------------+ | | | | | | | | test_realm | | | | Realm- | DB | | | +-------------+ | | | Specific | Server| | +-----------------+ | | Environment | | | | Components| | | | +-----------+-------+ | | Node-Specific | | Environment Components | +-----------------------------+ || LAN ================================================================ NODE1 || NODE2 || +-----------------------------+ +-----------------------------+ | MY_REALM TS_REALM | |MY_REALM | |+------------+ +------------+| |+------------+ | ||Realm- | |Realm- || || Realm- | | ||Specific | |Specific || || Specific | | ||Environment | |Environment || ||Environment | | ||Components | |Components || ||Components | | || | | || || | | |+------------+ +------------+| |+------------+ | | Node-Specific | | Node-Specific | | Environment Components | | Environment Components | +-----------------------------+ +-----------------------------+ 4-9 5 _________________________________________________________________ Environment Management Procedures This chapter describes the procedures that allow you to manage the BASEstar Open environment. You must perform the operations in the order prescribed: 1. Set up Nodes, Realms and databases on PODB nodes. A setup operation creates files and directories for the corresponding component. 2. Start up Nodes, Realms and Realm PODB servers. A startup operation runs the system processes that constitute the active part of the given component. 3. Shut down Nodes, Realms and Realm PODB servers. A shutdown operation terminates the system processes in an orderly fashion. 4. Unset Realms, Nodes and Realm PODB servers. An unset operation deletes files and directories for a specified component. You must set up a Realm before you can start it up. However, it is not necessary to set up all the components in order to start up just one of them. The BASEstar Open environment management procedures described in this chapter refer to the BASEstar Open environment commands documented in Chapter 6. Before issuing any of these commands, read the command description given in Chapter 6, which also highlights prerequisites and constraints. 5-1 Environment Management Procedures 5.1 Setup Procedures 5.1 Setup Procedures This section describes the procedures that you must use to set up Nodes and Realms. Execute the procedure described in Section 5.1.1, Setting Up a Node for each Node to be set up, and the procedure described in Section 5.1.2, Setting Up a Realm for all the Realms in your environment. For information regarding the parameters used by the procedures described in this chapter, refer to the relative man pages. 5.1.1 Setting Up a Node To create Node-specific directories and configuration files, use the bstr_node_setup command , located in $BSTR_ ROOT_INSTALL/var/opt/bstbase300/etc/ . For example, this command allows you to select the Node on which to activate the Name Service server. If you use the advanced bstr_ node_setup option, it allows you to select the BASEstar Open working directory root database, and the communication configuration parameters. When you set up a Node, BASEstar Open usually asks you to specify just the names of the nodes on which you want it to start the primary and secondary copies of the Name Service servers. On the PODB node, it also prompts you to provide details of the selected database. The bstr_node_setup command also creates the bstrusers.* command files, for setting up installation-dependent global variables (see Appendix B). 5.1.2 Setting Up a Realm You must set up a Realm for each Node on which the Realm is to be available, as explained in Section 5.1.2.1, Setting Up a Realm on a Node. If you wish to store Realm object definitions in the PODB, create a database for the Realm on the PODB Node (see Section 5.1.2.2, Setting Up the Realm Database on the PODB Node). 5-2 Environment Management Procedures 5.1 Setup Procedures 5.1.2.1 Setting Up a Realm on a Node The bstr_realm_setup_node command allows you to create the directories and files that are required at run-time by the internal Realm components started on the Node. 5.1.2.2 Setting Up the Realm Database on the PODB Node To create a database for a Realm, run the bstr_realm_setup_ db command on the PODB node. 5.1.3 Setting Up the Sample Environment The following command sequence demonstrates how to set up the BASEstar Open environment for the sample configuration illustrated in Figure 4-1. Note that these instructions cause BASEstar Open to activate the primary copy of the Name Service server on NODE2 and the secondary copy on NODE1. You can set up the Nodes shown in this example in any order. For details of the rules governing the execution of environment commands, refer to Chapter 6. Setting Up the Nodes Log in as SYSTEM on NODE1 and issue the following command: $ bstr_node_setup -l WORK1:[BASESTAROPEN030] -y ... LNS.Server_Node [NODE1]: NODE2 LNS.Server_Node_2[]: NODE1 ... Issue the following command on NODE2: $ /usr/opt/bstbase300/etc/bstr_node_setup -l /usr/opt/bstbase300 -y ... LNS.Server_Node [NODE2]: NODE2 LNS.Server_Node_2[]: NODE1 DB.node_is_cfg_server ?: FALSE ... Issue the following command on NODE_DB: 5-3 Environment Management Procedures 5.1 Setup Procedures $ /usr/opt/bstbase300/etc/bstr_node_setup -l /usr/opt/bstbase300 -y ... LNS.Server_Node [NODE_DB]: NODE2 LNS.Server_Node_2[]: NODE1 DB.node_is_cfg_server ?: TRUE Pathname of your ORACLE kit (II_SYSTEM): /usr/kits/oracle ... Setting Up the MY_REALM Realm To set up the MY_REALM Realm on NODE1, NODE2 and NODE_DB, execute the appropriate setup file for your shell on each Node: $ . /etc/bstrusers.sh (Sh or Sh5 shell) $ source /etc/bstrusers.csh (C shell) Then issue the following command on NODE1 (you can set up the Realms on the Nodes in any order): $ bstr_realm_setup_node MY_REALM Then issue the following command on NODE2: $ bstr_realm_setup_node MY_REALM Issue the following commands on NODE_DB: $ bstr_realm_setup_node MY_REALM $ bstr_realm_setup_db MY_REALM Setting Up the TS_REALM Realm To set up the TS_REALM Realm on NODE1 and NODE_DB, issue the following command on NODE1: $ bstr_realm_setup_node TS_REALM The setup operations for TS_REALM are similar to those performed for MY_REALM. Note that TS_REALM has not been set up on NODE2. This is because there was no request for the Realm to be available on this Node. Issue the following commands on NODE_DB: $ bstr_realm_setup_node TS_REALM $ bstr_realm_setup_db TS_REALM 5-4 Environment Management Procedures 5.2 Startup Procedures 5.2 Startup Procedures This section describes the procedures that allow you to start up a Node or a Realm in the BASEstar Open environment. You must execute the procedure described in Section 5.2.1, Starting Up a Node for each Node that you wish to start up. Execute the procedure described in Section 5.2.2, Starting Up a Realm for each Realm that you wish to make available in your environment. 5.2.1 Starting Up a Node The bstr_node_start command activates the node-specific components, and checks for license and environment integrity on the Node. Note that the started Nodes only become available when you start up the Node on which the Name Service server is activated. 5.2.2 Starting Up a Realm Start up the Realm on each Node on which you want the Realm to be available (see Section 5.2.2.1). You must also start up the Database Services server process (allowing access to the Realm database) on the PODB node (see Section 5.2.2.2). 5.2.2.1 Starting Up a Realm on a Node The bstr_realm_start_node command starts up Realm-specific components on the Node on which it is executed. It also checks for license and environment integrity on the Node. ________________________ Note ________________________ BASEstar Open components that are active on a Node cannot access components that are active on other Nodes until you start up the Node where the Name Service server resides. ______________________________________________________ 5.2.2.2 Starting Up the Database Server for a Realm on the PODB Node You must only use the bstr_realm_start_db command on the PODB node. This command activates the Database Services server for the specified Realm. 5-5 Environment Management Procedures 5.2 Startup Procedures 5.2.3 Starting Up the Sample Environment The command sequence in this section demonstrates how to start up the BASEstar Open environment for the sample configuration illustrated in Figure 4-1. Starting Up the Nodes You can start up the sample Nodes in any order. Issue the following command on NODE1: $ bstr_node_start Issue the following command on NODE2: $ bstr_node_start Issue the following command on NODE_DB: $ bstr_node_start Starting Up the MY_REALM Realm To start up MY_REALM on NODE1, NODE2 and NODE_DB, execute the command sequence illustrated below (you can start up the Realm on the Nodes in any order). To set up the MY_REALM Realm on NODE1, NODE2 and NODE_DB, execute the appropriate setup file for your shell on each Node: $ . /etc/bstrusers.sh (Sh or Sh5 shell) $ source /etc/bstrusers.csh (C shell) Then issue the following command on NODE1: $ bstr_realm_start_node MY_REALM Issue the following command on NODE2: $ bstr_realm_start_node MY_REALM Issue the following commands on NODE_DB: $ bstr_realm_start_node MY_REALM $ bstr_realm_start_db MY_REALM If you execute the above command sequence correctly, BASEstar Open makes the MY_REALM Realm available. At this point, you can start up the Realm application components using, for example, the Application Management Services as explained in the BASEstar Open Command Language Interface. 5-6 Environment Management Procedures 5.2 Startup Procedures Starting Up the TS_REALM Realm To start up TS_REALM on NODE1 and NODE_DB, issue the following command on NODE1: $ bstr_realm_start_node TS_REALM Issue the following commands on NODE_DB: $ bstr_realm_start_node TS_REALM $ bstr_realm_start_db TS_REALM The startup operations for TS_REALM are similar to those performed for MY_REALM. Note that TS_REALM has not been started up on NODE2, since there was no request for the Realm to be available on this Node. 5-7 Environment Management Procedures 5.3 Shutdown Procedures 5.3 Shutdown Procedures This section describes the procedures that allow you to shut down a Node and a Realm in the BASEstar Open environment. You must execute the procedure described in Section 5.3.1, Shutting Down a Realm for each Realm that you wish to be make unavailable in your environment. You must also execute the procedure described in Section 5.3.2, Shutting Down a Node for each Node to be made unavailable in your environment. 5.3.1 Shutting Down a Realm To shut down a Realm in an orderly fashion, you must first shut down the application components. To do so, use either the command interpreter on your platform or the Application Management Services. You must then shut down the active Database Services server on the Realm PODB node (see Section 5.3.1.1). Finally, you must shut down the Realm on each Node where the Realm was started, as explained in Section 5.3.1.2. ________________________ Note ________________________ It is possible to shut down a Realm on one Node and leave it available on the remaining Nodes. However, it is recommended that you shut down all the Realm application components in an orderly fashion on all Realm Nodes before shutting down the Realm environment on the Node. ______________________________________________________ 5.3.1.1 Shutting Down the Database Server for a Realm on the PODB Node The bstr_realm_shut_db command stops the Realm Database Services server. You can only perform this operation on the PODB node. 5.3.1.2 Shutting Down a Realm on a Node The bstr_realm_shut_node command makes a Realm unavailable on a Node. It also shuts down any active realm-specific components on the Node. 5-8 Environment Management Procedures 5.3 Shutdown Procedures 5.3.2 Shutting Down a Node The bstr_node_shut command deactivates the node-specific environment components. Note that once you have completed the shutdown operation for the Node on which the Name Service server is running, BASEstar Open becomes unavailable on all other Nodes unless you activate a secondary copy of the server on a Node that is still active. 5-9 Environment Management Procedures 5.3 Shutdown Procedures 5.3.3 Shutting Down the Sample Environment The command sequence in this section demonstrates how to shut down the BASEstar Open environment for the sample configuration illustrated in Figure 4-1. Shutting Down the MY_REALM Realm You can shut down MY_REALM on NODE1, NODE2 and NODE_DB in any order. Before shutting down the Realm on the PODB Node, you must first issue the bstr_realm_shut_db command on that Node. Execute the appropriate setup file for your shell on each Node: $ . /etc/bstrusers.sh (Sh or Sh5 shell) $ source /etc/bstrusers.csh (C shell) Issue the following command on NODE1: $ bstr_realm_shut_node MY_REALM Issue the following command on NODE2: $ bstr_realm_shut_node MY_REALM Issue the following commands on NODE_DB: $ bstr_realm_shut_db MY_REALM $ bstr_realm_shut_node MY_REALM Shutting Down the TS_REALM Realm To shut down TS_REALM on NODE1 and NODE_DB, issue the following command on NODE1: $ bstr_realm_shut_node TS_REALM Issue the following commands on NODE_DB: $ bstr_realm_shut_db TS_REALM $ bstr_realm_shut_node TS_REALM The shutdown operations for TS_REALM are similar to those performed for MY_REALM. ________________________ Note ________________________ You do not need to be a superuser (root) to shut down a Realm. However, the user who shuts down the Realm must be the same user that started up the Realm. ______________________________________________________ 5-10 Environment Management Procedures 5.3 Shutdown Procedures Shutting Down the Nodes Once you have shut down MY_REALM and TS_REALM in an orderly fashion, you can shut down the Nodes in any order. Issue the following command on NODE1: $ bstr_node_shut Issue the following command on NODE2: $ bstr_node_shut Issue the following command on NODE_DB: $ bstr_node_shut 5-11 Environment Management Procedures 5.4 Unset Procedures 5.4 Unset Procedures This section describes the procedures that allow you to unset Realms and Nodes. Execute the procedure described in Section 5.4.1, Unsetting a Realm for all the Realms in your environment, and the procedure described in Section 5.4.2, Unsetting a Node for all the Nodes to be unset. 5.4.1 Unsetting a Realm Unsetting a Realm implies unsetting it for all the Nodes on which it was set, as described in Section 5.4.1.1, Unsetting a Realm from a Node. In addition, you must delete the PODB database created for that Realm, as explained in Section 5.4.1.2, Unsetting a Realm Database on the PODB Node. 5.4.1.1 Unsetting a Realm from a Node To unset a Realm from a Node, execute the bstr_realm_unset_ node command on the Node in question. This command deletes all realm-specific directories and files previously created by the bstr_realm_setup_node command from the file system of the Node. The PODB node also performs the actions described in Section 5.4.1.2. 5.4.1.2 Unsetting a Realm Database on the PODB Node To unset a Realm database on the PODB node, execute the bstr_realm_unset_db command on the PODB node. This command deletes the database for the specified Realm. ________________________ Note ________________________ If you delete the database for a specified Realm, BASEstar Open also deletes all PODB object definitions. ______________________________________________________ 5.4.2 Unsetting a Node The bstr_node_unset command deletes the directories and node-specific files previously created by the bstr_node_setup command from the file system of the Node. 5-12 Environment Management Procedures 5.4 Unset Procedures 5.4.3 Unsetting the Sample Environment The command sequence in this section demonstrates how to unset the BASEstar Open environment for the sample configuration illustrated in Figure 4-1. Unsetting the MY_REALM Realm You can unset the MY_REALM Realm from NODE1, NODE2 and NODE_DB in any order. Issue the following command on NODE1: $ bstr_realm_unset_node MY_REALM Issue the following command on NODE2: $ bstr_realm_unset_node MY_REALM Issue the following commands on NODE_DB: $ bstr_realm_unset_db MY_REALM $ bstr_realm_unset_node MY_REALM Unsetting the TS_REALM Realm To unset the TS_REALM Realm on NODE1 and NODE_DB, issue the following command on NODE1: $ bstr_realm_unset_node TS_REALM Issue the following commands on NODE_DB: $ bstr_realm_unset_db TS_REALM $ bstr_realm_unset_node TS_REALM The operations required to unset TS_REALM are similar to those performed for MY_REALM. Note that TS_REALM has not been unset from NODE2. This is because it was not set on this Node. Unsetting the Nodes You can unset the Nodes shown in the example in any order. Issue the following command on NODE1: $ bstr_node_unset Issue the following command on NODE2: $ bstr_node_unset Issue the following command on NODE_DB: $ bstr_node_unset 5-13 Environment Management Procedures 5.5 Monitoring BASEstar Open 5.5 Monitoring BASEstar Open In addition to the general management procedures, you can use the bstr_mon tool (or the bstr_env_show command) to monitor the active components of the BASEstar Open environment. It displays: o All available Realms o For each Realm, the Nodes on which the Realm is available, and the available Domains and VMDs o A list of available Nodes and Realms available on each Node. For a complete description of the bstr_mon tool, refer to Chapter 7. Refer to Chapter 6 for a description of the bstr_env_show command. You can also use the bstr_realm_check_env command to check whether the BASEstar Open environment has been set up and started up successfully on a given Node. 5-14 6 _________________________________________________________________ Environment Management Command Reference 6.1 Executing Environment Commands This section outlines the general requirements for successful execution of environment commands. Specific command requirements are given in the description of each individual command. If you execute a command successfully, BASEstar Open returns the following exit status: 0 (zero) If a command fails, it returns a different value in the command exit status. It also displays one or more messages that provide information about the error(s) that occurred during execution of the command. The log file often contains additional information about the components used to execute the command (see Chapter 10). 6.1.1 Requirements and Constraints This section indicates the types of users that can issue environment management commands, and specifies the rules that you must follow when issuing a command. 6.1.1.1 Users and Commands Not all users can issue all the environment management commands. Table 6-1 indicates which user can issue a given command, where: o Root represents the superuser 6-1 Environment Management Command Reference 6.1 Executing Environment Commands o Spool user indicates a user responsible for managing a given Node. For a given Node, the spool user is the root user (default) or the user whose name was specified when the advanced bstr_node_setup command was executed for that Node. o Realm user indicates the user who has the task of managing a given Realm. For a given Realm, the Realm user is the user who issued the bstr_realm_setup_node command for that Realm. o Generic user indicates any UNIX user. ________________________ Note ________________________ If root, spool user or Realm user is specified for a command, it means that only that particular user can issue the command. ______________________________________________________ Table 6-1 Relationship Between Environment Management __________Commands_and_Users_______________________________ Command_______________Type_of_User_________________________ ____________________Monitoring_Commands____________________ bstr_env_show Generic user bstr_realm_check_env Generic user ___________________________________________________________ __________________Node_Management_Commands_________________ bstr_node_setup Root bstr_node_start Spool user bstr_node_shut Spool user bstr_node_unset Root (continued on next page) 6-2 Environment Management Command Reference 6.1 Executing Environment Commands Table 6-1 (Cont.) Relationship Between Environment __________________Management_Commands_and_Users____________ ___________________________________________________________ _________________Realm_Management_Commands_________________ bstr_realm_setup_ Realm user node bstr_realm_start_ Realm user node bstr_realm_shut_node Realm user bstr_realm_unset_ Realm user node bstr_realm_setup_db Realm user bstr_realm_start_db Realm user bstr_realm_shut_db Realm user bstr_realm_unset_db___Realm_user___________________________ 6.1.1.2 Issuing a Command You must follow the rules listed below when executing an environment command (except for the bstr_node_setup command, for which refer to the instructions given in the command description): o Log in as the appropriate user (as specified in Table 6-1) on the selected UNIX Node. o Ensure that the installation-dependent global variables have been correctly set by executing the bstrusers.sh, or bstrusers.csh script files. (See Appendix B for details.) For specific information on command requirements and constraints, refer to the description of each individual command. 6-3 Environment Management Command Reference 6.2 Privileges Needed to Run Environment Management Procedures 6.2 Privileges Needed to Run Environment Management Procedures Table 6-2 lists the privileges required to run the various BASEstar Open environment management operations. Table_6-2_Environment_Management_Privileges________________ Privileges Required Phase_________________Procedure________for_Execution_______ Set up BASEstar Open bstr_node_setup Superuser Start up BASEstar bstr_node_start Superuser Open Shut down BASEstar bstr_node_shut Superuser Open Unset BASEstar Open bstr_node_unset Superuser Set up a Realm bstr_realm_ Normal user setup_node Start up a Realm bstr_realm_ Normal user start_node Shut down a Realm bstr_realm_ Normal user shut_node Unset a Realm bstr_realm_ Normal user unset_node Set up a database bstr_realm_ Normal user setup_db Start up a database bstr_realm_ Normal user start_db Shut down a database bstr_realm_ Normal user shut_db Unset a database bstr_realm_ Normal user ______________________unset_db_____________________________ 6-4 bstr_env_show _________________________________________________________________ bstr_env_show This command displays information on the environment components (Nodes and Realms) and services (server activities, PODB and Application Management Services servers currently started up in the BASEstar Open environment. Syntax bstr_env_show -q query [-s] | -d Description The bstr_env_show command allows you to display information on the components active in your BASEstar Open environment. It displays information on Nodes, Realms, or services, depending on what is specified in the query argument of the -q qualifier. The bstr_env_show command displays the components that are active at the time the command is issued (it does not provide information on components that have been set up but not started). To issue the bstr_env_show command: o Log in as a generic user. (See Section 6.1 for details.) o Check that the BASEstar Open environment has been started up successfully on the Node where the bstr_ env_show command is to be issued. (See Chapter 5 for details.) Note that this command accesses the Node where the Name Service server is active. o Ensure that the BASEstar Open installation-dependent global variables have been appropriately set, by executing the bstrusers.sh or bstrusers.csh script file. (See Appendix B for details.) If the command completes successfully, a zero value is returned in the command exit status, otherwise a value other than zero is returned. 6-5 bstr_env_show Options -q query The query expression specifies the kind of information that is displayed by the bstr_env_show command. The following expressions are valid: o N Displays the list of available BASEstar Open Nodes, that is, the nodes for which the bstr_node_start command has been executed, whose components have been started up successfully. o R Displays, for each Realm, the list of the BASEstar Open Nodes on which the Realm is available. (In this context, a Realm is considered to be available on a given Node if the Communication Service is found active and running on that Node.) o n[:node_name] Displays the list of Realms currently available on the node_name Node. The services currently available for each Realm are also shown, together with the resources made available by each type of service. (In this context, a Realm is considered to be available on a given Node if the Communication Service component is found active and running on that Node.) Several lines may be displayed, each containing the name of a Realm, the identifier of a service currently available on that Realm (ams, dtm, dvm, evm, or podb), and the associated resource (if significant). If you do not specify the node_name argument, the name of the Node on which the command is issued is assumed by default. o r[:realm_name] For the realm_name Realm, displays the list of services available on the Nodes where realm_name is available, together with the list of resources that are made available by each service. (In this context, a Realm is considered to be available on a given Node if the 6-6 bstr_env_show Communication Service component is found active and running on that Node.) Several lines may be displayed, each containing the identifier of an available service (ams, dtm, dvm, evm, or podb), the name of the Node on which the corresponding server is started up, and the associated resource (if significant). If you do not specify the realm_name argument, the name of the Realm set in the BSTR_REALM global variable is assumed by default. o s:[realm_name ]:ams|dtm|dvm|evm|mgm|podb For the realm_name Realm, displays the list of available services of a specified type (ams, dtm, dvm, evm, or podb), and informs you of the Node on which they are available. The resource (Domain or VMD) made available by each service is also displayed, where applicable. Several lines may be displayed, each containing the name of the Node on which the corresponding server is started up, and the associated resource (if significant). If you do not specify the realm_name argument, the name of the Realm set in the BSTR_REALM global variable is assumed by default. o d:[realm_name]:domain_name For the domain_name Domain belonging to the realm_name Realm, the command displays which Event Services server and Data Services server activities (evm or dtm) are available and on which Node the corresponding server has been started up. You must supply the full name of a Domain in the domain_name argument. Several lines may be displayed, each containing the identifier of the available service and the name of the Node where the service is available. If you do not specify the realm_name argument, the name of the Realm set in the BSTR_REALM global variable is assumed by default. 6-7 bstr_env_show -s Eliminates the display of the requested information. This option is useful when the bstr_env_show command is executed from a command file. To find out the result of the command execution, examine the command exit status. -d Displays a set of formatted records, which contain all the information that can be returned by the bstr_env_show command. Examples 1. $ bstr_env_show -q N *** BASEstar Nodes Started *** NODE **** sabato dennix This command displays the names of all the Nodes that are currently available in the BASEstar Open environment. 2. $ bstr_env_show -q R *** BASEstar Realms Started *** REALM NODE ***** **** PEASANT sabato TEST sabato TEST dennix This command displays the names of all the Realms that are currently available in your BASEstar Open environment. The name of the Node (or Nodes) on which the Realms are started is also displayed. The TEST Realm is started on both sabato and dennix Nodes, while the PEASANT Realm is started on the sabato Node only. 6-8 bstr_env_show 3. $ bstr_env_show -q n:sabato *** BASEstar Realms and Services for Node sabato *** REALM SERVICE DOMAIN VMD ***** ******* ****** *** PEASANT AMS PEASANT PODB TEST AMS TEST DTM /DTM_1 TEST DTM /DTM_2 TEST DTM /DTM_3 TEST EVM /EVM_1 TEST EVM /EVM_2 TEST MGM /MGM_1 This command displays the list of services that are available on Node sabato, sorted by Realm. 4. $ bstr_env_show -q r:TEST *** BASEstar Services for Realm TEST *** SERVICE NODE DOMAIN VMD ******* **** ****** *** AMS sabato DTM sabato /DOMAIN_1 DTM sabato /DOMAIN_2 DTM dennix /DOMAIN_3 EVM sabato /DOMAIN_1 EVM dennix /DOMAIN_2 This command displays the names of all the services that are started up in the TEST Realm. For each service, the command also displays the name of the Node where the service has been started up, and the name of the resource (or resources) made available by that service. In the example, both the Data Services server and the Event Services server have been started for the /DOMAIN_ 1 domain, and both on Node sabato. 6-9 bstr_env_show 5. $ bstr_env_show -q s:TEST:evm *** BASEstar Service EVM for Realm TEST *** NODE DOMAIN **** ****** sabato /DOMAIN_1 dennix /DOMAIN_2 This command shows that there are two active Event Services in the TEST Realm, for /DOMAIN_1 and /DOMAIN_ 2, respectively. It also shows the names of the Nodes where the corresponding Event Services servers have been started up (sabato and dennix Nodes, respectively). 6. $ bstr_env_show -q d:TEST:/DOMAIN_2 *** BASEstar Services for Domain /DOMAIN_2 of Realm TEST *** SERVICE NODE ******* **** EVM sabato This command shows that the server for the DOMAIN_2 Domain is currently available on Node sabato. See Also None. 6-10 bstr_node_setup _________________________________________________________________ bstr_node_setup This command creates directories and configuration files on the Node where it is executed, and allows you to define configuration parameters with regard to Name Service, BASEstar Open working directories, database, communication parameters and miscellaneous runtime parameters. Syntax bstr_node_setup -l location [-y | -adv] [-v] Description You must execute the bstr_node_setup command for each Node on which BASEstar Open must operate. You can only issue this command on a Node where BASEstar Open is installed. Before issuing the bstr_node_setup command you must log in as a root. The bstr_node_setup command is in the etc directory, under the BASEstar Open installation directory. You cannot issue the bstr_node_setup command if there are BASEstar Open processes currently active (all environment and application components must be shut down first). The bstr_node_setup command performs the following operations: o Creates configuration files for the Node-specific environment components. o Creates script files (one for "sh" and one for "csh") that can be used to set the values of the installation- dependent BASEstar Open global variables. (See Appendix B for details.) o Allows you to upgrade the /etc/services file for BASEstar Open network service daemons. (See services(5) and udp(4n).) o If ORACLE is installed, the bstr_node_setup command asks you to specify whether the Node is a PODB Node. If it is, it creates the database configuration file, and requests configuration parameters to be specified. 6-11 bstr_node_setup o Creates the subtree that stores the BASEstar Open temporary files created at run-time. To display some or all of the configuration parameters, select one of the following options: -y (default), or -adv. Options -l location Pathname of the directory where the BASEstar Open kit is installed. It must be an absolute pathname. -y Simplified Node setup. The only value you can supply is the name of the BASEstar Open Nodes where the primary and secondary copies of the Name Service server were activated. -adv Advanced Node setup. Same as the -y option. In addition, you can change the name and characteristics of the subtree under which the BASEstar Open temporary and snapshot files are stored at run time. -v This option displays additional information on the execution of the command. Usage Notes While executing the bstr_node_setup command, press to accept the default value that is displayed between square brackets ([]). Press at any time to abort the bstr_node_setup command. The lines displayed by the bstr_node_setup command start with different character strings, depending on the operation being performed. The following character strings can be displayed: o The @@@ string identifies a message that describes the operation in progress. o The &&& string identifies an error message (error or fatal error). 6-12 bstr_node_setup Lines that are displayed without any of the above character strings are input requests. ________________________ Note ________________________ The name of the less extensive option that displays a given parameter is specified within brackets. In other words, if the -y option is specified, it means that the parameter is also displayed by the -adv option. ______________________________________________________ Have you Specified the Right Directory? The bstr_node_setup command prompts you to know if the pathname specified by the -l option argument is correct. Do you want to set up the kit installed in installation_directory? [yes]: (-y option). Enter no to terminate the command execution immediately. Changing Configuration Parameters The bstr_node_setup command allows you to display and change the values of some configuration parameters. All the bstr_node_setup command prompts and displays are listed below. BSTR.Spool_Root [/usr/spool/bstr]: (-adv option). Pathname of the root directory for the temporary files subtree. BSTR.Spool_Owner [root]: (-adv option). Name of the user who owns the directory tree specified as BSTR.Spool_Root. BSTR.Spool_Group [users]: (-adv option). Name of the group that owns the directories tree specified as BSTR.Spool_Root (the entered name must correspond to an existing group). BSTR.Spool_Protection_Mode [0771]: (-adv option). Protection mask applied to the directories tree specified as BSTR.Spool_Root. The default value is 0771 (that is, "rwxrwx-"), which restricts directories access to the owner (BSTR.Spool_Owner) and the group (BSTR.Spool_Group). 6-13 bstr_node_setup LNS.Server_Node [current_node]: (-y option). Name of the Node where BASEstar Open muts activate the primary copy of the Name Service server. This parameter must have the same value on all the BASEstar Open Nodes. LNS.Server_Node_2 []: (-y option). This parameter is optional and specifies the name of the Node where BASEstar Open must activate the secondary copy of the Name Service server. If a value is entered for this parameter, it must be the same on all the Nodes. Note that the secondary copy of the Name Service server cannot be activated on the same Node specified for the primary copy. Specifying the Node Role The bstr_node_setup command asks whether client users active on the Node are allowed to access BASEstar Open servers active on Nodes other than this one. BSTR.Local_Only_Enabled ? [False] Enter True if the client users that will be activated on the Node being set up can only access BASEstar Open servers active on the same Node. Enter False to allow client users that will be activated on the Node being set up to access BASEstar Open servers active on the other configured Nodes. The bstr_node_setup command asks if your Node must act as a PODB Node. DB.node_is_cfg_server ? [False] Enter True if the Node being set up must act as a PODB Node, otherwise enter False. Creating Configuration and Script Files Once the values of the configuration parameters have been displayed and modified (optional), the bstr_node_setup command displays appropriate messages informing you that configuration and script files are being created or edited. Any original files are copied to files of the same name (with the ".old" extension), and they are maintained for recovery purposes, or for reading the old values. The following files are created: 6-14 bstr_node_setup o The installation_file.h_node_name, which contains all the configuration parameters you entered in response to the bstr_node_setup command prompts, together with some reserved configuration parameters. o The lns.conf file, which contains all the configuration parameters you entered in response to the bstr_node_ setup command prompts regarding the LNS network service. o The bstrusers.sh file, which is a Bourne shell script that allows users to set installation-dependent global variables. The file is created under the etc sub- directory of the BASEstar Open installation directory and is symbolically linked to /etc/bstruser.sh. (See Appendix B for details.) o The bstrusers.csh file, which is a Bourne shell script that allows users to set installation-dependent global variables. The file is created under the etc sub- directory of the BASEstar Open installation directory and is symbolically linked to /etc/bstruser.sh. (See Appendix B for details.) Upgrading the /etc/services File When the configuration and script files have been created, the bstr_node_setup command asks you to specify whether you wish to upgrade the /etc/services file in order to insert the BASEstar Open IP services used by the communication daemons. would you like to upgrade /etc/services ? [yes] @@@ upgrading /etc/services ... If you enter y, the bstr_node_setup command automatically upgrades the /etc/services file. Enter y or n, depending on the following considerations: o If the /etc/services file is not upgraded through yellow pages, enter y. o If the /etc/services file is upgraded through yellow pages, then: - If you are installing on a yellow pages master server, enter y. - Otherwise, enter n. 6-15 bstr_node_setup If you enter y (default), the original /etc/services file is copied to /etc/services.old. First of all, the command checks that there are no duplicated entries, and then it adds the BASEstar Open entries as appropriate. If a duplicated entry is found, the bstr_node_setup command asks you to indicate whether it is to be removed: remove existing entries? [yes] If you enter y, the duplicated entry is removed; if you enter n, the /etc/services file is not upgraded. If you chose not to upgrade /etc/services automatically, or the upgrade fails because of a duplicated entry, the bstr_node_setup command creates a file named etc/bstr_ services under the location directory. This file contains the records that should have been added to /etc/services. For instance, it could be used for a suitable upgrading of the "services" map (for example, using the Yellow Pages). However, it is up to the environment manager to upgrade /etc/services, or any other equivalent file used locally. Creating the Database Configuration File The questions shown below are only displayed if your Node is a PODB Node: DBA_Username [ORACLE]: Enter the name of the ORACLE user. DB_Identifier [BSTR]: Enter the ORACLE DBMS identifier. Initial_DB_datafile_Path [/node/cnf]: Initial_DB_RedoLog1_Path [/node/cnf]: Initial_DB_RedoLog2_Path [/node/cnf]: Initial_DB_Tables_Path [/node/cnf]: Initial_DB_Indexes_Path [/node/cnf]: Initial_DB_Rollseg_Path [/node/cnf]: 6-16 bstr_node_setup For each of the above requests, you must provide the following information: o Pathname of the database file that holds the ORACLE data dictionary o Pathname of the ORACLE Redo log files o Pathname of the database file that holds the BASEstar Open objects o Pathname of the database file that holds the BASEstar Open indexes o Pathname of the database file that holds the rollback segments o Pathname of the database file that holds the temporary segments At this point, the bstr_node_setup command creates the DB_parameters.h_node_name database configuration file and inserts the database SID in /etc/oratab. Creating BASEstar Open Work Directories Finally, the bstr_node_setup command creates the basic BASEstar Open work directories using the specified values. If the root directory (or a subdirectory) already exists, a message is displayed asking for confirmation before removing it. On completion, the bstr_node_setup command returns you to the shell prompt. Examples 1. $ /usr/kits/bstr300/etc/bstr_node_setup -adv @@@ Using default kit_location: /usr/kits/bstr300 LNS.Server_Node [NODE1]: NODE2 do you want to setup the kit installed in /usr/kits/bstr300? [yes]Y @@@ reading configuration... please wait... @@@ defining the basic communication parameters ... 6-17 bstr_node_setup ------------------------- The answers to the following questions control the configuration of the work directories and the users authorized to access them, i.e. to work with BASEstar. ------------------------- Name of the BASEstar work and shapshot subdirectories root: BSTR.Spool_Owner [root]: Name of the group authorized to access the BASEstar work subdirectories: BSTR.Spool_Group [users]: Protection Mask of the BASEstar work subdirectories (octal value): BSTR.Spool_Protection_Mode [0771]: Name of the host where the primary LNS Server will run: LNS.Server_Node [NODE1]: NODE2 Name of the host where the secondary LNS Server will run: --- Note that the primary and secondary LNS Server Hosts cannot coincide. LNS.Server_Node_2 []: NODE1 ------------------------- The answers to the following questions control what global daemons have to be started at node startup (i.e., by bstr_node_start). ------------------------- Answer True if you want local-only realms to be active on the node. BSTR.Local_Only_Enabled [False]: Answer True if this node will run the Database Server. DB.node_is_cfg_server ? [FALSE] True @@@ creating shell setup file /usr/kits/bstr300/etc/bstrusers.sh ... @@@ creating shell setup file /usr/kits/bstr300/etc/bstrusers.sh.h_naxos3 ... @@@ creating c-shell setup file /usr/kits/bstr300/etc/bstrusers.csh ... @@@ creating c-shell setup file /usr/kits/bstr300/etc/bstrusers.csh.h_naxos3 ... @@@ creating shell setup file /usr/kits/bstr300/etc/bstradmin.sh ... @@@ creating shell setup file /usr/kits/bstr300/etc/bstradmin.sh.h_naxos3 ... 6-18 bstr_node_setup @@@ creating c-shell setup file /usr/kits/bstr300/etc/bstradmin.csh ... @@@ creating c-shell setup file /usr/kits/bstr300/etc/bstradmin.csh.h_naxos3 ... @@@ creating /usr/kits/bstr300/etc/lns.conf.h_naxos3... would you like to upgrade /etc/services ? [yes] @@@ upgrading /etc/services ... @@@ moving /etc/services in /etc/services.old ... @@@ going to create the BASEstar spool directory, @@@ containing the BSTR_WORK_ROOT and BSTR_DBACCESS_KEY subdirectories. $ If you are logged in to NODE_DB, the bstr_node_setup command creates the BASEstar Open static structures on NODE_DB. In addition, BASEstar Open expects the primary copy of the Name Service server to be available on NODE2 and the secondary copy on NODE1. NODE_DB is also set up as a PODB Node. 6-19 bstr_node_shut _________________________________________________________________ bstr_node_shut Shuts down the Node-specific environment components. Syntax bstr_node_shut [-h] [-v] Description The bstr_node_shut command shuts down the Node-specific components. Before issuing this command, you are advised to shut down all the Realms that are available on the Node (issue the bstr_realm_shut_node command for each Realm, or specify the -h option). If you are working on a PODB Node, this command also performs an orderly shutdown of the ORACLE daemon processes. Options -h If you specify this option, the bstr_node_shut command also shuts down all the Realms that are available on the Node. In other words, the bstr_realm_shut_node command is automatically issued for each available Realm. If you do not specify this option (default), the bstr_node_ shut command checks whether there are any Realms started up on the Node. If the command finds one or more Realms still active, it lists them and terminates without performing any actions. -v This option displays additional information on the execution of the command. 6-20 bstr_node_shut Examples 1. $ bstr_node_shut If you are logged in to NODE1, the bstr_node_shut command shuts down the node-specific environment components on that Node. See Also bstr_node_start 6-21 bstr_node_start _________________________________________________________________ bstr_node_start Starts up the node-specific environment components. Syntax bstr_node_start [-v] [-c] Description The bstr_node_start command starts up the node-specific environment components and checks for license and environment integrity on the Node. Issue the bstr_node_start command for each Node where BASEstar Open is to be started up. Before issuing the bstr_node_start command, you must issue the bstr_node_setup command to set up the Node. Issue this command before you issue the bstr_realm_start_ node and bstr_realm_start_db commands. Starting up a Node does not affect operations on other Nodes, where one or more Realms could be already started up. However, remember that all the Nodes you started up become available once you have started up the Node where the Name Service server resides. If you are working on a PODB Node, this command also starts up the ORACLE daemon processes. On completion, the bstr_node_start command outputs messages notifying you of its successful completion (all the node- specific components have been started up), or unsuccessful completion (no components have been started up). Options -v This option displays additional information on execution of the command. -c 6-22 bstr_node_start If you specify this option, the bstr_node_start command performs a cleanup of all the temporary files for the current Node and all the Realms that have been set up on it. For example, it deletes working files and purges the Log Services files. Examples 1. $ bstr_node_start If you are logged in to NODE1, the bstr_node_start command starts up the node-specific components on that Node. See Also bstr_node_setup bstr_node_shut 6-23 bstr_node_unset _________________________________________________________________ bstr_node_unset Deletes the directories and configuration files previously created using the bstr_node_setup command from the Node where the command is executed. Syntax bstr_node_unset [-l location ] [-v] Description You cannot issue the bstr_node_unset command if there are BASEstar Open processes active (all environment and application components must be shut down first). Before issuing the bstr_node_unset command, shut down all the Realms that are currently available on the Node and the Node itself. The bstr_node_unset command performs the following actions: o Deletes the Node-specific BASEstar Open working directory. o Deletes the snapshot directory specified for the Node. Because a snapshot directory can be shared among many Nodes, the shared snapshot directory (which resides on only one Node) is physically deleted only when all the Nodes that share it have been unset. When executed on a PODB Node, this command also deletes all the DBMS structures that were created using the bstr_realm_ setup_db command. The DBMS configuration files are also deleted. Once issued, the bstr_node_unset command displays a request for confirmation before deleting the BASEstar Open-related entries from the /etc/services file. On a PODB Node, the database SIDs are also deleted from the /etc/oratab file. 6-24 bstr_node_unset Options -l location Pathname of the directory where the BASEstar Open kit is installed. It must be the same pathname as that specified while setting up BASEstar Open. -v This option displays additional information on the execution of the command. Examples 1. $ bstr_node_unset If you are logged in to NODE1, this command deletes the BASEstar Open static structures on that Node. See Also bstr_node_setup 6-25 bstr_realm_check_env _________________________________________________________________ bstr_realm_check_env Checks whether the BASEstar Open environment has been set up and started up successfully. Syntax bstr_realm_check_env[realm_name] Parameters realm_name Specifies the local name of the Realm to be checked. If this parameter is specified, the bstr_realm_check_env command checks that realm_name matches the value of the BSTR_REALM global variable. Description The check is performed on the Node on which the command is issued. Once invoked, the bstr_realm_check_env command performs the following: o If the realm_name parameter is specified, it checks whether the BSTR_REALM global variable has been set and whether its value is equal to realm_name. o Checks whether the installation-dependent global variables have been set (that is, if the appropriate bstrusers script has been executed successfully). o Checks whether the directories specified in the installation-dependent global variables exist and have appropriate contents (that is, if the bstr_realm_ setup_node command has been executed successfully on the Node). o Checks whether the account you are using is authorized to operate on the BASEstar Open environment. (See Section 6.1 for details.) 6-26 bstr_realm_check_env If any of the above checks fails, the bstr_realm_check_env command displays an error message and returns control to the command interpreter. Otherwise, a series of messages are displayed to inform you that the realm_name Realm has been set up successfully on the Node. In addition, the bstr_realm_check_env command tells you whether or not the Realm has been started up successfully on the Node. To issue the bstr_realm_check_env command: o Log in as a generic user on the Node for which you wish to check the BASEstar Open environment. (See Section 6.1 for details.) o Ensure that the BASEstar Open installation-dependent global variables have been set successfully, by executing the bstrusers.sh or bstrusers.csh script file. (See Appendix B for details.) o Set BSTR_REALM with the name of the Realm to be checked. If the command completes successfully, a zero value is returned in the command exit status, otherwise a value other than zero is returned. Examples 1. $ setenv BSTR_REALM MY_REALM bstr_realm_check_env BASEstar Open Realm Environment Check for the Realm: MY_REALM Global Environment Variables: Correctly Set. Working Environment Existence: Correctly built. Working Environment access: Accessible. REALM : MY_REALM Currently Active If you are logged in to NODE2, this command checks whether the MY_REALM Realm has been set up successfully. All preliminary checks were successful and MY_REALM has been started up on NODE2. 6-27 bstr_realm_check_env See Also None. 6-28 bstr_realm_setup_db _________________________________________________________________ bstr_realm_setup_db Creates a DBMS-dependent database where you can store PODB object definitions for the specified Realm. Syntax bstr_realm_setup_db realm_name [-c] [-l location] Parameters realm_name Specifies the local name of the Realm for which the database is to be created. The login and password name for the database are those of the specified Realm. Description Issue this command on the Realm PODB Node only, after you have set up the PODB Node, using the bstr_node_setup command. The bstr_realm_setup_db command first checks if snapshots still exist for realm_name. If it is so, an error message is displayed and no PODB database is created. To force the command to delete the snapshots, you must specify the -c qualifier. The bstr_realm_setup_db command writes additional information to the _setup_db.log file created under the $BSTR_WORK_ROOT/realm/realm_name/tmp directory. 6-29 bstr_realm_setup_db Options -c Forces the command to delete any existing snapshots for realm_name. -l location Not allowed. See Also bstr_node_setup 6-30 bstr_realm_setup_node _________________________________________________________________ bstr_realm_setup_node Creates directories and files to be used at run time by the realm-specific environment components started on the Node. Syntax bstr_realm_setup_node realm_name [-v] Parameters realm_name Specifies the local name of the Realm for which the structures (files and directory) are to be created. The realm_name string can have a maximum of 8 uppercase characters and must follow the syntax rules of a BASEstar Open local name. Description Before issuing the bstr_realm_setup_node command, issue the bstr_node_setup command to set up the Node. Options -v This option displays additional information on the execution of the command. Examples 1. $ bstr_realm_setup_node MY_REALM If you are logged in to NODE1, the bstr_realm_setup_node command creates the BASEstar Open static structures for MY_REALM. 6-31 bstr_realm_setup_node See Also bstr_node_setup bstr_realm_unset_node 6-32 bstr_realm_shut_db _________________________________________________________________ bstr_realm_shut_db Shuts down the Database Service server for the specified Realm. Syntax bstr_realm_shut_db realm_name Parameters realm_name Specifies the local name of the Realm for which the Database Service server is to be shut down. Description Issue the bstr_realm_shut_db command on the PODB Node only. This must be the first operation you perform in the realm_name shutdown process. Before issuing the command, you must ensure that there are no transactions in progress on the database. In other words, check that all the application components have been shut down in an orderly fashion, and that no CLI or Graphical Configuration Utility operators are working on the PODB definitions for realm_name. Examples 1. $ bstr_realm_shut_db MY_REALM If you are logged in to the PODB Node (NODE_DB), the bstr_realm_shut_db command shuts down the Database Service server for MY_REALM. See Also bstr_realm_start_db 6-33 bstr_realm_shut_node _________________________________________________________________ bstr_realm_shut_node Shuts down Realm-specific environment components for the Node on which it is executed. Syntax bstr_realm_shut_node realm_name [-h] [-v] Parameters realm_name Specifies the local name of the Realm on which the realm- specific environment components are to be shut down. Description Issue the bstr_realm_shut_node command on a given Node for a given Realm to make the specified Realm unavailable on the Node. The bstr_realm_shut_node command performs the following steps: o Shuts down the PC Communication server. o Shuts down the Application Management Services server and therefore terminates the Activities and Programs under its control. o Shuts down the Global Object Services server. o Shuts down the Communication Service. The Communication Service processes are only stopped after termination of the application components. Note that the -h option causes the Communication Service to terminate unconditionally, without waiting for the Application Components to terminate. Before issuing this command, shut down the Realm application components as appropriate. If you are operating on a PODB Node, issue the bstr_realm_ shut_db command before issuing the bstr_realm_shut_node command. 6-34 bstr_realm_shut_node Options -h When this option is specified, the bstr_realm_shut_node command also forces all the realm-specific environment components active on the Node to terminate. If this option is not specified (default), the Communication Service component is only terminated when there are no more Realm environment or application components active on the Node. -v This option displays additional information on the execution of the command. Examples 1. $ bstr_realm_shut_node MY_REALM If you are logged in to NODE1, this command shuts down the internal components on the specified Node for MY_ REALM. See Also bstr_realm_start_node 6-35 bstr_realm_start_db _________________________________________________________________ bstr_realm_start_db Starts the Database Service server for the specified Realm. Syntax bstr_realm_start_db realm_name Parameters realm_name Specifies the local name of the Realm for which the Database Service server is to be started. Description Issue the bstr_realm_start_db command on the Realm PODB Node only. This command starts up the Database Service server, which allows BASEstar Open users to access the Realm PODB in order to create, update and delete object definitions for realm_name. Before issuing the bstr_realm_start_db command, you must create the appropriate database using the bstr_realm_setup_ db command, and start up the Realm on the PODB Node using the bstr_realm_start_node command. See Also bstr_realm_setup_db bstr_realm_shut_db 6-36 bstr_realm_start_node _________________________________________________________________ bstr_realm_start_node Starts up the realm-specific environment components on the Node. Syntax bstr_realm_start_node realm_name [-v] -w work_dir Parameters realm_name Specifies the local name of the Realm for which the environment components are to be started up. Description Issue the bstr_realm_start_node command on a given Node for a given Realm to make the specified Realm available on the Node. Before issuing the bstr_realm_start_node command, start up the Node using the bstr_node_start command, and set up the Realm on the same Node using the bstr_realm_setup_node command. Note that the user-defined global variables that you set before issuing this command are visible to the Application Management Services server. Therefore, they are also visible to all processes (that is, Programs) started by the server. (See Section 8.3.1 for further details.) In addition, if you wish to specify a different port number for the PC Communication server, set the new value in the BSTR_PC_PORT global variable. The bstr_realm_start_node command performs the following steps: 1. Starts up the Communication Service. 2. Starts up the Global Object Services server. 3. Starts up the Application Management Services server. 6-37 bstr_realm_start_node 4. Starts up the PC Communication server. 5. Checks for license and environment integrity on the Node. Options -w work_dir This option specifies the pathname of the directory where BASEstar Open stores Realm-specific work files. The specified directory must exist. -v Displays additional information on the execution of the command. Examples 1. $ bstr_realm_start_node MY_REALM If you are logged in to NODE1, the bstr_realm_start_node command starts up MY_REALM on that Node. See Also bstr_realm_setup_node bstr_realm_shut_node 6-38 bstr_realm_unset_db _________________________________________________________________ bstr_realm_unset_db Deletes the database that contains the PODB definitions for the specified Realm. Syntax bstr_realm_unset_db realm_name [-s] Parameters realm_name Specifies the name of the Realm whose database is to be deleted. Description Issue the bstr_realm_unset_db command to delete the database associated with realm_name. BASEstar Open deletes the specified database, together with its contents. ________________________ Note ________________________ Deleting the database for a specified Realm means deleting all its PODB object definitions. ______________________________________________________ The bstr_realm_unset_db command performs the physical deletion of the PODB database for the specified Realm only if there are no other Nodes still set for that Realm. Note that the bstr_realm_unset_db command is automatically executed by the bstr_realm_unset_node command. If the -s option is specified, the bstr_realm_unset_db deletes all the object definitions for realm_name but not the snapshot configurations. Options -s If this option is specified, the bstr_realm_unset_db deletes all the object definitions for realm_name but leaves the snapshot configurations. 6-39 bstr_realm_unset_db See Also bstr_realm_setup_db 6-40 bstr_realm_unset_node _________________________________________________________________ bstr_realm_unset_node Deletes directories and files previously created using the bstr_realm_setup_node procedure. Syntax bstr_realm_unset_node realm_name [-v] Parameters realm_name Specifies the local name of the Realm for which the structures (files and directories) are to be deleted. Description Before issuing the bstr_realm_unset_node command, make sure that all the Realm and Node components active on the Node have been correctly shut down. The bstr_realm_unset_node command physically deletes the snapshots for realm_name only if no other Nodes are sharing them. Note that the bstr_realm_unset_node command also executes the bstr_realm_unset_db command automatically and, therefore, it removes the Realm PODB database. Options -v This option displays additional information on the execution of the command. Examples 1. $ bstr_realm_unset_node MY_REALM If you are logged in to NODE1, the bstr_realm_unset_node command deletes the BASEstar Open files and directories for MY_REALM. 6-41 bstr_realm_unset_node See Also bstr_realm_setup_node bstr_realm_shut_node 6-42 bstr_run _________________________________________________________________ bstr_run The bstr_run procedure is the BASEstar Open Running Procedure (BRP) allows you to have a Realm active even if the Node is not set up nor started. syntax bstr_run realm_name [-I] [-L location] [-NOPODB] [-NOVODB] [-RDB db_version] Parameters realm_name Is the name of the Realm that bstr_run must activate. The realm is created with the following default characteristics: o Single node o One domain, the root domain "/" o One AMS actor, named realm_name_SERVERS o Two activities, allowing the use of the volatile database (VODB), as follows: - EVM, (event manager) named /realm_name_SERVERS/EVM, which runs the program /realm_name_EVM_SERVER - DTM, (data manager) named /realm_name_SERVERS/DTM, which runs the program /realm_name_DTM_SERVER. If RDB is available on the system, permanent database (PODB) and DB server. The bstr_run procedure defaults can be overridden by using the relevant parameters and options. Options -I Enables the interactive execution of the bstr_run procedure. If this flag is specified, all the BASEstar Open environment procedures are executed interactively, and the bstr_run default values can be overridden 6-43 bstr_run The BASEstar Open environment procedures contain questions during their execution (for example, requiring confirmation, parameters, values, and so on); by default, the bstr_run procedure executes these procedures, suppressing any questions and using internal default values. -L location Specifies the pointer to the directory specification containing the BASEstar Open kit or where BASEstar Open was installed. This directory specification must be provided only if the Node is not currently set up. -NOPODB Causes bstr_run to skip the phase of setting up of the permanent database and starting its server. In this case, you can only configure objects in the volatile database. By default, bstr_run sets up the Realm environment in order to create the PODB and all structures required to use the permanent database. Furthermore it will also start the database server to enable the user to have an immediate access to PODB facilities. The -NOPODB flag inhibits the execution of this phase: so, no PODB access is allowed to the user. However, even if the -NOPODB flag is not specified, the bstr_run procedure realizes if the Node could be considered a "PODB Node" (that is, if a supported DBMS is installed) and, if not, skips the PODB setup-start phase automatically. -NOVODB Causes bstr_run to skip the phase of setting up and starting the volatile database facilities. By default, bstr_run sets up an AMS Actor containing two Activities related to EVM and DTM servers, where: o The name of the Actor is realm_name_SERVERS. o The full name of the Activity related to EVM server is "/realm_name_SERVERS/EVM" and the program executed by it is named "/realm_name_EVM_SERVER" 6-44 bstr_run o The full name of the Activity related to DTM server is "/realm_name_SERVERS/DTM and the program executed by it is named "/realm_name_EVM_SERVER" o The Node is the current one and the domain used is the root (/). This object is configured by using a CLI file (a script) created by bstr_run and named SYS$SCRATCH:AMS_SETUP_FILE.CLI. This file can also be used as an example of a simple AMS configuration. If only the -NOVODB flag is specified, this phase is skipped and the AMS objects must be created separately if a VODB access is required. However, even if the -NOVODB flag is not specified, this phase is only executed if the Realm has been started by bstr_run to avoid interferences with possible user configurations. -RDB db_version Specifies that the RDB version db_version be used to set the permanent database facilities. The RDB version must be provided only if more than one RDB version is present on the system. This parameter has no significance if the -NOPODB flag is set. Description The bstr_run procedure looks at the user's environment and performs all the operations needed to run BASEstar Open: using bstr_run, the user no longer needs to call all the DCL command procedures needed to set up and start BASEstar Open. For example, if the node has been already set up and started, bstr_run starts its activity from the execution of the bstr_realm_setup_node procedure. The bstr_run procedure runs the following BASEstar Open procedures to create a minimum BASEstar Open environment: 1. bstr_node_setup[1] 2. bstr_node_start[1] 3. bstr_realm_setup_node ____________________ [1] Requires all privileges 6-45 bstr_run 4. bstr_realm_start_node[2] 5. bstr_realm_setup_db 6. bstr_realm_start_db[2] The account from which the bstr_run procedure is run must have the requisite privileges for each of the constituent environment procedures. For more information on the privileges required to run each of the environment management procedures, refer to Section 6.2. The bstr_run procedure performs a "rollback" mechanism if some operation fails during its execution. The rollback mechanism involves only the operations previously performed by bstr_run, and not any operations that were already performed before bstr_run commenced execution. For example, if the node has been already set up and started when bstr_ run was run, the rollback affects only the subsequent steps and leaves the node in the state of "set and started. " In some circumstances, bstr_run sets up and starts the PODB and an Actor containing a couple of Activities, thus enabling you to work with Event and Data Services on both permanent and volatile databases. During execution, the bstr_run procedure displays only the basic messages relevant to its execution. Detailed information of each step of the execution is instead collected the log file SYS$SCRATCH:BRP_LOG_FILE.OUT. Examples 1. $ bstr_run SAMPLE In this example, the bstr_run procedure performs the steps required to set up the realm SAMPLE, and then performs the "rollback" mechanism on failure: o Sets up the Node o Executes the bstr_run procedure for the Realm SAMPLE. The bstr_run procedure then performs the following tasks: a. Starts Node ____________________ [2] Requires DETACH privilege 6-46 bstr_run b. Sets up Realm SAMPLE c. Starts Realm SAMPLE At this point, the starting up of Realm SAMPLE fails (either partially or completely). The bstr_run procedure continues as follows with the "rollback": d. Shuts Realm SAMPLE e. Unsets Realm SAMPLE f. Shuts Node o The bstr_run procedure then terminates. 6-47 7 _________________________________________________________________ BASEstar Open Environment Monitor 7.1 Introduction The BASEstar Open Environment Monitor is an interactive tool capable of displaying the Realms and Nodes that have been started up, together with their relationships in the BASEstar Open operating environment. It also displays the Domain Server resources that are available within a Realm. Domain Services Servers can be Data servers, Device servers, or Event servers. The bstr_mon tool is used to monitor the active components of the BASEstar Open environment; for example, started Nodes, Realms that are started on these Nodes and the services available for a given Realm. The bstr_mon tool can be used to display the following: o The available Realms o For each Realm, the Nodes on which the Realm is available, the available Domains and the VMDs o A list of the available Nodes and a list of Realms available on each Node. You can run the BASEstar Open Environment Monitor from any VTxxx terminal. The Monitor is user-friendly, with simple command keystrokes and consistent screen menus. It displays Realms (with associated services) and Nodes on two screens. The two views are: o Active Realm View - displays the active Realms. If you select a Realm, it displays the Nodes which made the Realm available to it, together with the Realm's associated services. o Active Node View - displays the active Nodes. If you select a Node, it displays the Realms made available for use on the Node. 7-1 BASEstar Open Environment Monitor 7.1 Introduction When the BASEstar Open Environment Monitor command is invoked, the default view is displayed (see Figure 7-1). The default view is the Active Realm View. 7-2 BASEstar Open Environment Monitor 7.2 Running the BASEstar Open Environment Monitor 7.2 Running the BASEstar Open Environment Monitor To run the BASEstar Open Environment Monitor perform the following steps: 1. Check that the BASEstar Open environment has been started up successfully on the Node that is to run the Monitor (see Chapter 5 for details). 2. Make sure that the installation-dependent global variables have been initialized for the login user. To initialize the installation dependent global variables, execute the bstrusers script. See Appendix B for details of global variables. 3. Enter the following from the command interpreter prompt: $ bstr_mon to display the view of the active Realms shown in Figure 7-1. 7.3 General Characteristics The general characteristics of the BASEstar Open Environment Monitor are described below. Refreshing Displayed Information The BASEstar Open Environment Monitor application retains information in its memory and you must therefore use the Update command to review the current environment. The screen is refreshed automatically every five minutes to display the current environment. The Update command can be executed in both views (mnemonic "U"). Quitting the Environment Monitor To exit from either view of the BASEstar Open Environment Monitor, execute the Quit Command (mnemonic "Q"). 7-3 BASEstar Open Environment Monitor 7.4 Views 7.4 Views The sections below explain how to operate on the BASEstar Open Environment Monitor Views. 7.4.1 Active Realm View The default view that is displayed when the BASEstar Open Environment Monitor is invoked is shown in Figure 7-1. The screen is divided into three windows. Figure 7-1 Active Realm View +------------------------------------------------------------------+ | ACTIVE REALMS | | ALAN guida | | BUSO | +------------------------------------+-----------------------------+ | DOMAINS M D D E | NODES P A | | G V T V | D M | | M M M M | B S | +------------------------------------+-----------------------------+ | /a o | COUGH | | | | | | | | | | | | | | | | | | | | | | | | | | | | +------------------------------------+-----------------------------+ The Active Realm window (upper window) displays a list of available Realms, sorted by name. If there are no names available, the screen displays "No active realms". The cursor is initially positioned in this window and the first Realm is highlighted. The cursor can be moved through the list of Realms by using the up and down cursor movement keys. 7-4 BASEstar Open Environment Monitor 7.4 Views When the cursor is positioned on a Realm, the list of resources (Domains and VMDs) for this Realm is displayed in the bottom left-hand window (the Domain window) and all the Nodes on which the Realm has been started up are displayed in the bottom right-hand window (the Node window). The Domain window displays the list of resources available in the Realm, sorted by name. If there are no resources available, the screen displays "No active domains". Each resource is displayed on a separate line. To the right of each line, a bullet is displayed indicating the type of server activity that makes the resource available, as follows: ___________________________________________________________ Identifier____Server_Activity______________________________ EVM Event Services server MGM Packet Services server DTM Data Services server DVM___________Device_Services_server_______________________ The following also applies: o If the bullet is positioned under EVM, MGM or DTM, the string to its left contains the full name of a Domain. o If the bullet is positioned under DVM, the string to its left contains the name of a VMD. The Node window displays the list of Nodes that have been started up for the selected Realm. If no Nodes have been started up, the screen displays "No active nodes". This window displays each Node on a separate line. Each line contains the following information: o The name of a Node o A bullet positioned under the PDB column, if the Database Service server is active on that Node o A bullet positioned under the AMS column, if the Application Management Services server is active on that Node. 7-5 BASEstar Open Environment Monitor 7.4 Views If it is not possible to view all of the information in the Domain window or Node window, you can select these windows by pressing the carriage return (ENTER) key (press the carriage return key again to select the Node window, and repeat this action to select the Active Realm window). You can then move the cursor through the list of Domains or Nodes using the up and down cursor movement keys. The command line at the bottom of the screen displays the available options. In the case of the Active Realm View, menu options include jumping to the Active Node View, Update, quitting the BASEstar Open Environment Monitor, or switching between windows, as follows: ___________________________________________________________ Option________Command_______Function_______________________ [ENTER]- Carriage To move between windows toggle return [ENTER] key Update U To refresh screen to display current BASEstar Open Environment Nodes N To invoke Node View Quit Q To exit BASEstar Open ____________________________Environment_Monitor____________ 7-6 BASEstar Open Environment Monitor 7.4 Views 7.4.2 Active Node View The screen is divided into two windows (see Figure 7-2). Figure 7-2 Active Node View +------------------------------------------------------------------+ | ACTIVE NODES | | ARFF | | COUGH | | DENNX | | SLAPP | | YAPP | | | | | | | | | +------------------------------------+-----------------------------+ | ACTIVE REALMS | +------------------------------------+-----------------------------+ | guida | | | | | | | | | | | +------------------------------------------------------------------+ The example in Figure 7-2 displays a list of the active Nodes in the BASEstar Open environment. The cursor is positioned on the Node "arff" and the bottom window therefore displays the list of Realms which have been made available on that Node. The Active Node window (top window) displays a list of Nodes, sorted by name. If there are no Nodes, the screen displays "No active nodes". If it is not possible to view all of the Nodes together, you can move the cursor through the list of Nodes using the up and down cursor movement keys. When you position the cursor on a Node, it is highlighted and automatically becomes the selected Node. 7-7 BASEstar Open Environment Monitor 7.4 Views The Active Realm window (bottom window) displays the list of Realms (sorted by name) that have been started up for the selected Node. If there are no Realms, the screen displays "No active realms". If it is not possible to view all of the Realms together, you can select this window by pressing the carriage return (ENTER) key and then move the cursor through the list of Realms using the up and down cursor movement keys. The command line at the bottom of the screen displays the available options. In the case of the Active Node View, menu options include jumping to the Active Realm View, Update, quitting the BASEstar Open Environment Monitor, or switching between windows, as follows: ___________________________________________________________ Option________Command_______Function_______________________ [ENTER]- Carriage To move between windows toggle return [ENTER] key Update U To refresh screen to display current BASEstar Open Environment Realms R To invoke Active Realm View Quit Q To exit BASEstar Open ____________________________Environment_Monitor____________ 7-8 8 _________________________________________________________________ BASEstar Open-Supplied Servers A BASEstar Open-supplied server is a system process that makes a set of BASEstar Open objects available at run-time. For each Realm, the following BASEstar Open servers make VODB objects available: o Event Services servers, which make the Event Services objects of one or more Domains available at run-time. o Packet Services servers, which make the Packet Services objects of one or more Domains available at run-time. o Data & Device Services servers, which make the following objects available at run-time: - Data Services objects of one or more Domains - One or more VMDs and associated Device Services server objects. o Global Object Services servers make the Realm global objects, such as Domains and VMDs, available at run- time. o The Application Management Services server, which makes the Application Management Services objects available at run-time and therefore provides the main functions for the activation, monitoring and control of the Realm application components (user-written applications, Data Services servers, Event Services servers, and Device Services servers). A Realm can contain additional optional servers that perform some specialized tasks for the Realm, such as: o A Database Services server, which provides access to the PODB object definitions. 8-1 BASEstar Open-Supplied Servers o A PC Communication server, which enables applications running on client Nodes to operate on Realm objects and object definitions like other BASEstar Open applications running on server Nodes. The rest of this chapter describes the characteristics of the different types of servers, and explains how to manage them. 8-2 BASEstar Open-Supplied Servers 8.1 Servers, Activities and Owned Resources 8.1 Servers, Activities and Owned Resources The Event Services servers, Packet Services servers, Data Services servers and Device Services servers are implemented as Application Management Services applications. This means that, at run-time, a server acts as a Program execution capable of executing several Activities. Depending on the kind of server, each Activity owns and thus makes available a specific set of resources (Domain) to BASEstar Open users. BASEstar Open servers (apart from Application Management Services servers), make VODB objects available once they have been started up. A BASEstar Open server is started up using the command interpreter features or the Application Management Services features described in the BASEstar Open Command Language Interface manual. The Realm Application Management Services servers are activated automatically as part of the Realm startup process (see Chapter 5). In order to activate a server using Application Management Services, you must configure it as a set of Activity objects associated with an appropriate Program object. 8.1.1 Snapshots When a server Activity is started up, it looks for the definitions of the default objects in a specific snapshot configuration. (Snapshots are created using CLI configuration commands.) The use of snapshots speeds up the operation that each Activity performs when loading default objects in the VODB. Of course, if the specified snapshot is not found, no default objects are created. For example, when a Data Services server Activity is started up, it makes objects such as Data_Points and Triggers available, whose definitions are contained in the snapshot for the associated Domain. At run-time, the same Activity allows for additional objects that are visible in that Domain to be created in the VODB. 8-3 BASEstar Open-Supplied Servers 8.1 Servers, Activities and Owned Resources 8.1.2 Logged Information Like many other BASEstar Open components, BASEstar Open servers write information to a log file. To find out how this information is logged, see Chapter 10. 8-4 BASEstar Open-Supplied Servers 8.2 Global Object Services 8.2 Global Object Services A Global Object Services server is the Realm-specific environment component that makes the global objects available on that Realm. It enables users to request services such as creating and getting attributes of global objects. The objects made available by Global Object Services belong to the following classes: o Datatype o Domains o VMD o Protocol_Profile o VMD_Extension_Parameter A Global Object Services server is started up on each Node where the Realm is started. Once started up, a Global Object Services server checks to see if another Global Object Services server has been started up on another Node for the same Realm, and then: o If it is the first to start up, looks for its snapshot in the most recently generated snapshot configuration and then creates its default objects in the VODB. o If it is not the first to start up, it does not load the configuration because it makes available objects that have been already loaded by the other Global Object Services servers in the Realm from the snapshot or that have been already created when fulfilling user service requests. To provide such dynamic and distributed services, the Global Object Services servers of a Realm continuously notify each other of their respective availability and of operations in progress. Once you have started up the Realm, you can use the LOAD CONFIGURATION command to force the active Global Object Services servers to load an alternative snapshot configuration. 8-5 BASEstar Open-Supplied Servers 8.2 Global Object Services A Global Object Services server supports up to 40 client application components. This limit is determined by the value of the BSTR_GOM_MAX_CLIENT variable. To increase the number of clients, follow these steps: 1. Locate the following section of code in the $BSTR_ETC/realm_startup/start05_gom.sh file: # # Define default GOM trace utility # BSTR_GOM_TRACE=GOM; export BSTR_GOM_TRACE 2. To set a maximum of 100 clients, enter the following code immediately below the above section: # # Define new GOM clients maximum limit # # BSTR_GOM_MAX_CLIENT=100; export BSTR_GOM_MAX_CLIENT 8-6 BASEstar Open-Supplied Servers 8.3 Application Management Services 8.3 Application Management Services The Application Management Services servers for a given Realm make the Application Management Services objects of that Realm available to clients. An Application Management Services server is started up on each Node where the Realm is started. The objects made available by Application Management Services belong to the following classes: o Activity o Actor o Node o Program Once started up, an Application Management Services server looks for a snapshot in the most recently generated snapshot configuration and then creates its default objects in the VODB. Once you have started up the Realm, you can use the LOAD CONFIGURATION command to request the active Application Management Services servers to load an alternative snapshot configuration. 8.3.1 Environment Variables - Inheritance and Usage During startup, an Application Management Services server inherits all the environment variables that were set before the bstr_realm_start_node command was issued. In addition, you can define new environment variables (or modify existing ones) in the Node environment and/or in the parameter file associated with each Program. (For information regarding the record format of these files, refer to Appendix C.) The value set to this type of environment variable is made available and can be used in various contexts. Table 8-1 explains when you can set a user-defined environment variable and the context in which you can use it. 8-7 BASEstar Open-Supplied Servers 8.3 Application Management Services Table_8-1_Environment_Variables_-_Validity_and_Usage_______ ______Environment_Variable_Usage_____ If_Set..._____________OBJS_PATH_____PARS_PATH__RET_VAR_____ Before issuing the Yes Yes Yes bstr_realm_start_node command In the environment Yes Yes Yes Node file (Cannot be used to express the Node environment file pathname) In the Program No No Yes parameter file Environment_Variable_Usage_________________________________ OBJS_PATH - Specifies the pathnames in the following Node and Program attributes: Node environment file, Program parameter file and Program image file. PARS_PATH - Forms the pathnames specified in the following Program parameter file items: input, output and error. RET_VAR - Available to a Program execution that can retrieve their value using the getenv() C run-time language function. ___________________________________________________________ 8-8 BASEstar Open-Supplied Servers 8.4 Event Services 8.4 Event Services One Event Services server can manage a maximum of 32 Activity executions. Each Activity execution makes the Event Services objects visible in the associated Domain available to users. The objects made available by Event Services belong to the following classes: o Enbox o Event o Event_Set Once started up, an Activity execution looks for the corresponding snapshot to create the default objects in the VODB. If no snapshot is found, no default VODB objects are created for the associated Domain. The executable name for the Program is evm_server. This executable is stored in the $BSTR_BIN directory (see Appendix B). 8.4.1 Using Application Management Services to Manage an Event Services Server An Event Services server must be configured as a Program, with a number of associated Activities that is equal to the number of Domains that it has to make available. Application Management Services start up the server when an execute message is sent to any of its Activities. For further information about how to configure and manage an Event Services server using Application Management Services, refer to the BASEstar Open Command Language Interface. 8.4.2 Starting Up and Shutting Down an Event Services Server from the Command Interpreter To start up an Event Services server from the command interpreter, run its executable image from the command interpreter prompt after having set the appropriate global variables. Remember that, in this case, an Event Services server can only execute one Activity; that is, it can only make one Domain available. 8-9 BASEstar Open-Supplied Servers 8.4 Event Services Before running the server, you must perform the following actions: o Set the name of the Activity in the BSTR_ACTIVITY global variable. This name bears no relation to any existing Application Management Services Activity object, and is simply a label used to identify messages in the LOG file. o Set the BSTR_DOMAIN global variable with the full name of the Domain that the server Activity is to make available. This name is also used to identify any corresponding snapshot. o Initialize the installation-dependent global variables by executing the bstrusers command file (see Appendix B). o Set the BSTR_REALM global variable with the name of the Realm on which the server is to operate. o Set the BSTR_DBVERSION and BSTR_DBACCESS_KEY global variables (optional). For further information about global variables and how to set them, refer to Appendix B. The example below shows how to start an Event Services server from cshell (the corresponding shell command sequence is easy to create). The server makes the /PLANT /PRODUCTION/LINE2 Domain available. The server creates the default objects whose definitions are contained in the snapshot configuration identified by a major identifier equal to 2. (BASEstar Open has been installed under the /usr/kits/bstr300 directory.) $ source /usr/kits/bstr300/etc/bstrusers.csh $ setenv BSTR_Realm MY_Realm $ setenv BSTR_ACTIVITY DATA_ACT_PRODUCTION_LINE1 $ setenv BSTR_DOMAIN /PLANT/PRODUCTION/LINE2 $ setenv BSTR_DBVERSION 2 $ evm_server & In the example, note that the server has been started as a background process; this is advisable, but not mandatory. 8-10 BASEstar Open-Supplied Servers 8.4 Event Services To stop an Event Services server, send any of the following signals: SIGINT, SIGKILL, SIGQUIT, and SIGTERM (see kill(1) manual section). Stopping a server with the SIGKILL signal (kill -9), causes it to exit without performing the cleanup phase (some files may be left in the BASEstar Open working directory). 8-11 BASEstar Open-Supplied Servers 8.5 Packet Services 8.5 Packet Services One Packet Services server can manage a maximum of 32 Activity executions. Each Activity execution makes the Packet Services objects visible in the associated Domain available to users. The objects made available by Packet Services belong to the following classes: o Packet o Port Once started up, an Activity execution looks for the corresponding snapshot to create the default objects in the VODB. If the snapshot is not found, no default VODB objects are created for the associated Domain. The executable name for the Program is mgm_server. This executable is stored in the $BSTR_BIN directory (see Appendix B). 8.5.1 Using Application Management Services to Manage a Packet Services Server A Packet Services server must be configured as a Program, with a number of associated Activities that corresponds to the number of Domains to be made available. Application Management Services start up the server when an execute message is sent to any of its Activities. For further information about how to configure and manage a Packet Services server using the Application Management Services, refer to the BASEstar Open Command Language Interface. 8.5.2 Starting Up and Shutting Down a Packet Services Server from the Command Interpreter To start up a Packet Services server from the command interpreter, run its executable image from the command interpreter prompt after having set the appropriate global variables. Remember that, in this case, a Packet Services server can only execute one Activity: that is, it can only make one Domain available. 8-12 BASEstar Open-Supplied Servers 8.5 Packet Services Before running the server, you must perform the following operations: o Set the name of the Activity in the BSTR_ACTIVITY global variable. This name bears no relation to any existing Application Management Services Activity object, and is simply a label used to identify messages in the LOG file. o Set the BSTR_DOMAIN global variable with the full name of the Domain that the server Activity is to make available. This name is also used to identify any corresponding snapshot. o Initialize the installation-dependent global variables by executing the bstrusers command file (see Appendix B). o Set the BSTR_REALM global variable with the name of the Realm on which the server is to operate. o Set the BSTR_DBVERSION and BSTR_DBACCESS_KEY global variables (optional). For further information about global variables and how to set them, refer to Appendix B. The example below shows how to start a Packet Services server from cshell (the corresponding shell command sequence is easy to create). The server makes the /PLANT /PRODUCTION/LINE2 Domain available. The server creates the default objects whose definitions are contained in the snapshot configuration identified by a major identifier equal to 2. $ source /usr/kits/bstr300/etc/bstrusers.csh $ setenv BSTR_REALM MY_Realm $ setenv BSTR_ACTIVITY PACKET_ACT_PRODUCTION_LINE2 $ setenv BSTR_DOMAIN /PLANT/PRODUCTION/LINE2 $ setenv BSTR_DBVERSION 2 $ mgm_server & In the example, note that the server has been started as a background process; this is advisable, but not mandatory. 8-13 BASEstar Open-Supplied Servers 8.5 Packet Services To stop a Packet Services server, send any of the following signals: SIGINT, SIGKILL, SIGQUIT, and SIGTERM (see kill(1) manual section). Stopping a server with the SIGKILL signal (kill -9) causes it to exit without performing the cleanup phase (some files may be left in the BASEstar Open working directory). 8-14 BASEstar Open-Supplied Servers 8.6 Data Services 8.6 Data Services A Data Services server can manage a maximum of 32 Activity executions. Each Activity execution makes the Data Services server objects visible in the associated Domain available to users. At startup, an Activity execution looks for the corresponding snapshot to create the default objects in the VODB. The executable name for the Program is ddm_server. This executable is placed in the $BSTR_BIN directory, located in the BASEstar Open installation directory (see Appendix B). 8.6.1 Environmental Variables This section describes the Data Services server environmental variables. For a full summary of the Data Services server environmental variables, refer to Table 8-2. Table_8-2_Data_Management-Environmental_Variables________________ Name__________________Description_______Default__Range___________ BSTR_ACTIVITY Activity name None Name of Activity (starting without Application Management Services) BSTR_DADE_STACT_TH_ Activity control 98304 21504 -> SIZE thread stack bytes MAXINT[1] bytes size BSTR_DATA_CLIENT_TH_ Client servicing 524288 21504 -> SIZE thread stack bytes MAXINT[1] bytes size BSTR_DATA_CONNH_TH_ Connection 98304 21504 -> SIZE handling thread bytes MAXINT[1] bytes stack size [1]Maximum_positive_value_in_a_signed_32-bit_integer,_expressed__ in decimal format, no mantissa & exp notation. (continued on next page) 8-15 BASEstar Open-Supplied Servers 8.6 Data Services Table_8-2_(Cont.)_Data_Management-Environmental_Variables________ Name__________________Description_______Default__Range___________ BSTR_DATA_FCONN_TH_ DATA <-> DEVICE 98304 21504 -> SIZE comm thread bytes MAXINT[1] bytes stack size BSTR_DATA_I_SIZE DATA management 250 250 -> MAXINT[1] initial memory Kbytes Kbytes pool BSTR_DOMAIN Domain name None Name of Domain (starting without Application Management Services) BSTR_REALM Realm to use None Name of Realm [1]Maximum_positive_value_in_a_signed_32-bit_integer,_expressed__ in decimal format, no mantissa & exp notation. _________________________________________________________________ 8.6.2 Using Application Management Services to Manage a Data Services Server A Data Services server is configured as a Program, with a number of associated Activities that is equal to the number of Domains that it has to make available. The Application Management Services start up the server when an execute message is sent to any of its Activities. For further information about how to configure and manage a Data Services server using the Application Management Services, refer to the BASEstar Open Command Language Interface. If you want to set one or more of the Data Services-specific global variables listed in Section 8.6.1, you must set them in the parameter file of the associated Program object. The example that follows shows a valid parameter file for a Data Services server. Refer to Appendix C for details of the general structure of parameter files. However, remember that for a Data Services server only the global variables listed in Section 8.6.1 must be specified. 8-16 BASEstar Open-Supplied Servers 8.6 Data Services /PROG_DATA_SERVER.env: BSTR_DATA_I_SIZE=1000 8.6.3 Starting Up and Shutting Down a Data Services Server from the Command Interpreter To start up a Data Services server from the command interpreter, run its executable image from the command interpreter prompt after having set the appropriate global variables. Remember that a Data Services server can only execute one Activity; that is, it can make only one Domain available. Before running the server, you must perform the following operations: o Set the name of the Activity in the BSTR_ACTIVITY global variable. This name bears no relation to any existing Application Management Services Activity object, but is simply a label used to identify messages in the LOG file. o Set the BSTR_DOMAIN global variable with the full name of the Domain that the server Activity is to make available. This name is also used to identify any corresponding snapshot. o Initialize the installation-dependent global variables by executing the bstrusers command file (see Appendix B). o Set the BSTR_REALM global variable with the name of the Realm on which the server is to operate. o Set the BSTR_DBVERSION and BSTR_DBACCESS_KEY global variables (optional). For further information about global variables and how to set them, refer to Appendix B. The example below shows how to start a Data Services server from cshell (the corresponding shell command sequence is easy to create). The server makes the /PLANT/PRODUCTION /LINE2 Domain available. The server creates the default objects whose definitions are contained in the snapshot configuration identified by a major identifier of 2. 8-17 BASEstar Open-Supplied Servers 8.6 Data Services $ source /etc/bstrusers.csh $ setenv BSTR_REALM MY_Realm $ setenv BSTR_ACTIVITY DATA_ACT_PRODUCTION_LINE1 $ setenv BSTR_DOMAIN /PLANT/PRODUCTION/LINE2 $ setenv BSTR_DBVERSION 2 $ ddm_server & In the example, note that the server has been started as a background process. This is advisable, but not mandatory. To stop a Data Services server, send it any of the following signals: SIGINT, SIGKILL, SIGQUIT, and SIGTERM (see kill(1) manual section). Stopping a server with the SIGKILL signal (kill -9) causes it to exit without performing the cleanup phase (some files may be left in the BASEstar Open working directory). 8-18 BASEstar Open-Supplied Servers 8.7 Device Services 8.7 Device Services One Device Services server can manage a maximum of 32 Activities, each capable of making a VMD and all its associated Device Services objects available. At run-time, each Activity looks for its VMD snapshot in the current snapshot configuration (specified during execution of the LOAD CONFIGURATION command). The objects made available by Device Services belong to the following classes: o Named_Variable o Polling_Set o Protocol_Profile o Unnamed_Variable o VMD o VMD_Extension_Parameter The executable name for the Program is ddm_server. This executable is placed in the $BSTR_BIN directory, under the BASEstar Open installation directory (see Appendix B). 8.7.1 Global Variables This section describes the global variables for a Device Services server. 8.7.1.1 Specifying the Calling VMD Some protocols require you to specify the addresses of both the calling and the called partner VMDs, so that the Device Services server can establish an association with the plant device. Before starting up the Device Services server from the command interpreter or the Application Management Services, specify the name of the calling VMD in the BSTR_LOCAL_VMD_NAME global variable. 8-19 BASEstar Open-Supplied Servers 8.7 Device Services 8.7.1.2 Specifying the Connection Retry Timeout to a VMD The value assigned to the BSTR_RETRY_CONN_TIME variable specifies how many seconds the Device Services server waits before trying to restart the association with the VMD after a failure. The default value is 30 seconds. For a full summary of the Device Services server environmental variables, refer to Table 8-3. Table_8-3_Device_Management-Environmental_Variables______________ Name__________________Description_______Default__Range___________ BSTR_ACTIVITY Activity name None Name of Activity (starting without Application Management Services) BSTR_DADE_STACT_TH_ Activity control 98304 21504 -> SIZE thread stack bytes MAXINT[1] bytes size BSTR_DEVICE_GEN_TH_ DEVICE general 131072 21504 -> SIZE thread stack bytes MAXINT[1] bytes size BSTR_DEVICE_I_SIZE DEVICE 50 50 -> MAXINT[1] management Kbytes Kbytes initial memory pool BSTR_LOCAL_VMD_NAME Local VMD name None Name of Local VMD BSTR_POLLING_FACTOR Time scale 1 1 -> 100 factor for Polling Sets BSTR_REALM Realm to use None Name of Realm BSTR_RETRY_CONN_TIME Connection retry 30 1 -> MAXINT[1] time for VMDs seconds seconds [1]Maximum_positive_value_in_a_signed_32-bit_integer,_expressed__ in decimal format, no mantissa & exp notation. (continued on next page) 8-20 BASEstar Open-Supplied Servers 8.7 Device Services Table_8-3_(Cont.)_Device_Management-Environmental_Variables______ Name__________________Description_______Default__Range___________ BSTR_VMD VMD name None Name of VMD (starting without Application Management ______________________Services)__________________________________ 8.7.2 Using Application Management Services to Manage a Device Services Server Configure a Device Services server as a Program, with a number of associated Activities that is equal to the number of VMDs that it has to make available. Application Management Services start up the server when an execute message is sent to any of its Activities. For further information about how to configure and manage a Device Services server using the Application Management Services, refer to the BASEstar Open Command Language Interface. If you want to set one or more of the Device Services global variables listed in Section 8.7.1, you must set them in the parameter file of the associated Program object. The example that follows shows a valid parameter file for a Device Services server. Refer to Appendix C for details of the general structure of parameter files. However, remember that for a Data Services server only the global variables listed in Section 8.7.1 must be specified. /PROG_DEVICE_SERVER_1.env: BSTR_LOCAL_VMD_NAME=DV_CALLING_VMD_1 /PROG_DEVICE_SERVER_1.env: BSTR_RETRY_CONN_TIME=15 8.7.3 Starting Up and Shutting Down a Device Services Server from the Command Interpreter To start up a Device Services server from the command interpreter, run its executable image from the prompt after having set the appropriate global variables. Before running the server, you must perform the following actions: o Set the names of the Activities in the BSTR_ACTIVITY global variable. These names bear no relation to any 8-21 BASEstar Open-Supplied Servers 8.7 Device Services existing Application Management Services Activity objects, but are simply labels used to identify messages in the LOG file. Names must be separated by blanks. o Set the BSTR_VMD global variable with the name of the VMD that the server Activity is to make available. These names are also used to identify the corresponding snapshot. o Initialize the installation-dependent global variables by executing the bstrusers command file (see Appendix B). o Set the BSTR_REALM global variable with the name of the Realm on which the server is to operate. o Set the BSTR_DBVERSION and BSTR_DBACCESS_KEY global variables (optional). For further information about global variables and how to set them, refer to the Appendix B. The example that follows shows how to start a Device Services server from cshell (the corresponding shell command sequence is easy to create). The server makes the PLC1 VMD available. $ source /etc/bstrusers.csh $ setenv BSTR_REALM MY_Realm $ setenv BSTR_ACTIVITY DVM_SERVER_PLC1 $ setenv BSTR_VMD PLC1 $ setenv BSTR_DBVERSION 2 $ ddm_server & Note that in this example the server has been started as a background process; this is advisable, but not mandatory. To stop a Data Services server, send it any of the following signals: SIGINT, SIGQUIT, and SIGTERM (see kill(1) manual section). Stopping a server with the SIGKILL signal (kill -9) causes it to exit without performing the cleanup phase (some files may be left in the BASEstar Open working directory). 8-22 BASEstar Open-Supplied Servers 8.8 Combined Data & Device Services 8.8 Combined Data & Device Services The BASEstar Open Data & Device Services combine under a single server the functionality provided by the individual Data Services and Device Services components. This improves performance by eliminating the need for inter-process communication between the Data Manager (DTM) and the Device Manager (DVM). 8.8.1 Environmental Variables Table 8-4 contains a full summary of the Data & Device Services server environmental variables. Table_8-4_Data_and_Device_Management-Environmental_Variables_____ Name__________________Description_______Default__Range___________ BSTR_ACTIVITY Activity name None Name of Activity (starting without Application Management Services) BSTR_CONN_MODE Local VMD ACTIVE ACTIVE, PASSIVE connection behavior BSTR_DADE_STACT_TH_ Activity control 98304 21504 -> SIZE thread stack bytes MAXINT[1] bytes size BSTR_DATA_CLIENT_TH_ Client servicing 524288 21504 -> SIZE thread stack bytes MAXINT[1] bytes size BSTR_DATA_CONNH_TH_ Connection 98304 21504 -> SIZE handling thread bytes MAXINT[1] bytes stack size BSTR_DATA_FCONN_TH_ DATA <-> DEVICE 98304 21504 -> SIZE comm thread bytes MAXINT[1] bytes stack size [1]Maximum_positive_value_in_a_signed_32-bit_integer,_expressed__ in decimal format, no mantissa & exp notation. (continued on next page) 8-23 BASEstar Open-Supplied Servers 8.8 Combined Data & Device Services Table 8-4 (Cont.) Data and Device Management-Environmental __________________Variables______________________________________ Name__________________Description_______Default__Range___________ BSTR_DATA_I_SIZE DATA management 250 250 -> MAXINT[1] initial memory Kbytes Kbytes pool BSTR_DEVICE_GEN_TH_ DEVICE general 131072 21504 -> SIZE thread stack bytes MAXINT[1] bytes size BSTR_DEVICE_I_SIZE DEVICE 50 50 -> MAXINT[1] management Kbytes Kbytes initial memory pool BSTR_DOMAIN Domain name None Name of Domain (starting without Application Management Services) BSTR_LOCAL_VMD_NAME Local VMD name None Name of Local VMD BSTR_POLLING_FACTOR Time scale 1 1 -> 100 factor for Polling Sets BSTR_REALM Realm to use None Name of Realm BSTR_RETRY_CONN_TIME Connection retry 30 1 -> MAXINT[1] time for VMDs seconds seconds BSTR_VMD VMD name None Name of VMD (starting without Application Management Services) [1]Maximum_positive_value_in_a_signed_32-bit_integer,_expressed__ in decimal format, no mantissa & exp notation. _________________________________________________________________ 8-24 BASEstar Open-Supplied Servers 8.8 Combined Data & Device Services 8.8.2 Using the Data & Device Services to Support Passive Connections As an alternative to establishing a connection to a physical device, you can instruct the Data & Device Services server to wait passively for connection requests from the device. To configure the Data & Device Services server to do this, follow these steps: 1. Define the BSTR_LOCAL_VMD_NAME environment variable as the local VMD name. 2. Define the BSTR_CONN_MODE environment variable as "PASSIVE"[1]. The example below establishes a passive connection via the local VMD name DATADEV_CALLING_VMD_1. /PROG_DEVICE_SERVER_1.env: BSTR_LOCAL_VMD_NAME=DATADEV_CALLING_VMD_1 /PROG_DEVICE_SERVER_1.env: BSTR_CONN_NODE=PASSIVE ____________________ [1] If you do not define BSTR_CONN_MODE variable, or if you define it as "ACTIVE", the Data & Device Services server establishes the connection actively 8-25 BASEstar Open-Supplied Servers 8.9 PC Communication Servers 8.9 PC Communication Servers Using a PC Communication server, it is possible for BASEstar Open applications running on client Nodes to manage objects of a Realm that has been started up on the server Nodes of a distributed BASEstar Open environment. A PC Communication server accepts TCP/IP service requests from BASEstar Open MS Windows client Nodes and dispatches them to the appropriate Realm servers. BASEstar Open starts a PC Communication server on all the Nodes where the Realm is started. It is important that you remember this so that you can balance the load of each PC Communication server (and consequently of each Node) by configuring the client Nodes appropriately. (See the BASEstar Open Client Management Guide for details of how to install, configure and manage BASEstar Open on client PCs.) 8-26 9 _________________________________________________________________ Application Management Services Monitor 9.1 Introduction The Application Management Services Monitor is capable of detecting and displaying changes in the attributes of the Application Management Services objects of a given Realm as they occur. Attribute changes are generally caused by the following events: o Messages sent to the objects in question from users that issue CLI commands, or applications that invoke API procedures; for example, an Actor executed via the ACTOR EXECUTE CLI command. o Asynchronous occurrences that take place within the system resources; for instance, an Activity execution that terminates autonomously, or a system proceess in which a Program execution is run, that terminates abnormally. You can run the Application Management Services Monitor from any VTxxx terminal; the information displayed always reflects the real time situation. The Monitor is user- friendly, with simple command keystrokes and consistent screen menus. When you invoke the Application Management Services Monitor, the default view is displayed as shown in Figure 9-1. (The Actor View is the default view.) 9-1 Application Management Services Monitor 9.1 Introduction Figure 9-1 Actor View (default) +------------------------------------------------------------------+ | ACTOR: ACTOR_1 | | | +------------------------------------+-----------------------------+ | / | ACTOR ATTRIBUTES | | | | | | +---- ACTOR_1 | State: RUNNING | | +---- ACTOR_2 | Description: (N/A) | | | Start prio: 10 | | | Shut prio: 40 | | | Recovery: NECESSARY | | | Enabled: ENABLED | | | | | | | | | | | | | +------------------------------------+-----------------------------+ | ACTIVITY_1 ACTIVITY_4 | | ACTIVITY_2 SERVER_ACTIVITY | | ACTIVITY_3 | +------------------------------------------------------------------+ The Monitor displays several screens of objects, together with their associated attributes. These screens are called views. There is one view for each Application Management Services object: o Actor view o Activity view o Program view o Process view o Node view 9.2 Running Application Management Services Monitor To run the Application Management Services Monitor, perform the following steps: 1. Check that the BASEstar Open environment has been started up successfully on the Node that is to run the Monitor (see Chapter 5 for details). 9-2 Application Management Services Monitor 9.2 Running Application Management Services Monitor 2. Make sure that the installation-dependent global variables have been initialized for the login user. To initialize the installation-dependent global variables, execute the bstrusers script. You must also define the BSTR_REALM global variable as the name of the Realm that you want to address. For further information about global variables, refer to Appendix B. 3. Enter the following from the command interpreter prompt: $ ams_mon Once invoked, the Application Management Services Monitor displays the default view (see Figure 9-1). 9.3 General Characteristics The general characteristics of the Application Management Services Monitor are described below. Attribute Windows The Application Management Services Monitor displays the attributes of an Application Management Services object by means of Attribute windows. Each attribute is displayed on a separate line, in two columns (one column contains the name of the attribute field and the other contains its value). The names of the attribute fields do not always strictly correspond to the names of the attributes in the BASEstar Open Reference Guide, as they are often abbreviated. However, they always call the corresponding attribute, unless otherwise specified. Command Line The command line at the bottom of the screen displays the available options for the current view. These options include moving from one view to another, toggling to another window on a selected object, changing the cursor mode or quitting the Application Management Services Monitor. The options are accessed by selecting the highlighted mnemonic or by pressing the key for toggle (see Figure 9-1). 9-3 Application Management Services Monitor 9.3 General Characteristics Selected Object When the cursor is positioned on an object, the object is highlighted and automatically becomes the selected object. Truncated Fields Fields that do not fit into a window are truncated and the # symbol is displayed to the left and/or right of the field, depending on where it was truncated. Truncated fields may be viewed in their entirety by positioning the cursor on the required object and then scrolling to the left or right using the following keys: ___________________________________________________________ Key______________Function__________________________________ SPACE Scroll left DELETE___________Scroll_right______________________________ Cursor Mode The default mode is user-mode, where the cursor is user- driven; that is, it only moves when instigated by the user. In the follow-updates mode, the cursor follows the Application Management Services objects as they are updated. In this mode, the cursor is automatically positioned on the most recently modified object in the current view. To invoke Cursor Mode, enter the mnemonic command "M". The Application Management Services Monitor remains within the same view and the command line at the bottom of the screen appears as shown in Figure 9-2. 9-4 Application Management Services Monitor 9.3 General Characteristics Figure 9-2 Cursor Mode +------------------------------------------------------------------+ | ACTOR: ACTOR_1 | | | +------------------------------------+-----------------------------+ | / | ACTOR ATTRIBUTES | | | | | | +---- ACTOR_1 | State: RUNNING | | +---- ACTOR_2 | Description: (N/A) | | | Start prio: 10 | | | Shut prio: 40 | | | Recovery: NECESSARY | | | Enabled: ENABLED | | | | | | | | | | | | | +------------------------------------+-----------------------------+ | ACTIVITY_1 ACTIVITY_4 | | ACTIVITY_2 SERVER_ACTIVITY | | ACTIVITY_3 | +------------------------------------------------------------------+ To select the required option, enter the mnemonic command "U" (User-mode), or "F" (Follow-updates). Once the required command has been invoked, the view returns to its previous state. Quit To exit from the Application Management Services Monitor within any view, select the Quit option (mnemonic "Q"). 9.4 Views The following sections explain how to operate on the Application Management Services views. 9-5 Application Management Services Monitor 9.4 Views 9.4.1 Actor View Figure 9-3 shows the default view when the Application Management Services Monitor is invoked and displays the Actor objects defined in the Realm. The screen is divided into three windows. Figure 9-3 Actor View with Actor Attributes +------------------------------------------------------------------+ | ACTOR: ACTOR_1 | | | +------------------------------------+-----------------------------+ | / | ACTOR ATTRIBUTES | | | | | | +---- ACTOR_1 | State: RUNNING | | +---- ACTOR_2 | Description: (N/A) | | | Start prio: 10 | | | Shut prio: 40 | | | Recovery: NECESSARY | | | Enabled: ENABLED | | | | | | | | | | | | | +------------------------------------+-----------------------------+ | ACTIVITY_1 ACTIVITY_4 | | ACTIVITY_2 SERVER_ACTIVITY | | ACTIVITY_3 | +------------------------------------------------------------------+ The example in Figure 9-3 shows two Actor objects. The cursor is positioned on the Actor object ACTOR_1 and therefore displays the component Activities of that Actor in the bottom window. The attribute window displays the attributes of that Actor. The upper left window is the Actor Tree window, which displays the Realm Actor tree. The highlighted cursor is initially positioned in this window. You can use the cursor movement keys to move around the tree of Actor objects by means of the up and down cursor movement keys. 9-6 Application Management Services Monitor 9.4 Views When the cursor is positioned on an Actor, the full name of the Actor is displayed on the top line of the screen. The component Activities of the selected Actor are listed in the bottom window (the Activity window). The attributes of the selected Actor object are displayed in the upper right window (the attribute window). The Actor tree is displayed in order of name. The Actor names have different terminal attributes, depending on their current Actor state, as follows: ___________________________________________________________ Terminal Attribute________Actor_State_______________________________ Normal IDLE Blink STARTING Highlight RUNNING Blink + SHUTTING Highlight Normal PARTIALLY_RUNNING Normal___________RECOVERY_IN_PROGRESS______________________ The Activity window at the bottom of the screen displays the list of Activities that are components of the selected Actor. In order to display the attributes of an Activity, select the Activity window by pressing . Should it not be possible to view all the Activities at the same time, you can use the up and down cursor movement keys to move the cursor through the list of Activity objects and then select the required Activity object. The attribute window displays the attributes of the selected Activity. The top line of the screen displays the full name of the Activity. 9-7 Application Management Services Monitor 9.4 Views Figure 9-4 Actor View with Activity Attributes +------------------------------------------------------------------+ | ACTIVITY: /ACTOR_1/SERVER_ACTIVITY | | | +------------------------------------+-----------------------------+ | / | ACTOR ATTRIBUTES | | | | | | +---- ACTOR_1 << | Description: (N/A) | | +---- ACTOR_2 | Program: /program_example_2 | | | Profile: (N/A) | | | Running on: current_node | | | State: RUNNING | | | Breakpoints: | | | Start prio: 10 | | | Shut prio: 230 | | | Start tim.: 30 | | | Shut tim.: 30 | | | Recovery: NECESSARY | | | | +------------------------------------+-----------------------------+ | ACTIVITY_1 ACTIVITY_4 | | ACTIVITY_2 SERVER_ACTIVITY | | ACTIVITY_3 | +------------------------------------------------------------------+ The example in Figure 9-4 illustrates the Activity components of the Actor ACTOR_1. The cursor is positioned on the Activity SERVER_ACTIVITY and the attribute window displays its attributes. Press the key to select the Actor window once again. The command line at the bottom of the screen displays the available options. In the case of the Actors view, menu options include jumping to another view, changing the cursor mode, quitting the Application Management Services Monitor, or switching between the Actor window and the Activity window as follows: 9-8 Application Management Services Monitor 9.4 Views ___________________________________________________________ Option___________Command_____________Function______________ [ENTER] toggle key To move between windows aCtivities C To invoke Activity view Programs P To invoke Program view Processes R To invoke Process view Nodes N To invoke Node view cursor-Mode M User Mode or Follow Updates Quit Q To exit Application Management Services _____________________________________Monitor_______________ 9.4.2 Activity View Figure 9-5 illustrates how the Activity view displays all of the Activity objects existing in the Realm. The screen is divided into two windows. 9-9 Application Management Services Monitor 9.4 Views Figure 9-5 Activity View +------------------------------------------------------------------+ | PROGRAM: /program_example_1 | | | +------------------------------+-----------------------------------+ | program_example_1 | PROGRAM ATTRIBUTES | | program_example_2 | # instances: 1 | | program_example_3 | Kind: USER | | program_example_4 | Description: (N/A) | | | Parameters: #MPLE_ENV/programserv| | | Image: #LE_BIN)/program_11-1-an| | | | | | | | | | | | | | | | +------------------------------+-----------------------------------+ | 16640 RUNNING current_node | | | | | +------------------------------------------------------------------+ Activities are displayed in the Activity window. They are grouped according to Actor and sorted by full name. The top line of the screen displays the full name of the selected Activity and the Attribute window displays its attributes. The "Running On" attribute in the Attribute window is a combination of the start_enabled, master_state and current_ node attributes, that is, it can acquire values of all of these attributes. It can therefore acquire the following values: o DISABLED - same value as the start_enabled attribute o Not Running - a combination of the start_enabled attribute with the ENABLE value and the master_state attribute with the IDLE value o Name of the current Node - same value as the current_ node attribute 9-10 Application Management Services Monitor 9.4 Views The command line at the bottom of the screen displays the available options. In the case of the Activity view, menu options include jumping to another view, changing the cursor mode, or quitting the Application Management Services Monitor, as follows: ___________________________________________________________ Option___________Command_____________Function______________ Actors A To invoke Actor view Programs P To invoke Program view pRocesses R To invoke Process view Nodes N To invoke Node view cursor-Mode M User Mode or Follow Updates Quit Q To exit Application Management Services _____________________________________Monitor_______________ 9.4.3 Program View Figure 9-6 shows how all Program objects defined in the Realm are displayed in the Program view. The screen is divided into three windows. 9-11 Application Management Services Monitor 9.4 Views Figure 9-6 Program View +------------------------------------------------------------------+ | PROGRAM: /program_example_1 | | | +------------------------------+-----------------------------------+ | program_example_1 | PROGRAM ATTRIBUTES | | program_example_2 | # instances: 1 | | program_example_3 | Kind: USER | | program_example_4 | Description: (N/A) | | | Parameters: #MPLE_ENV/programserv| | | Image: #LE_BIN)/program_11-1-a | | | | | | | | | | | | | | | | +------------------------------+-----------------------------------+ | 16640 RUNNING current_node | | | | | +------------------------------------------------------------------+ The Program window is the upper left window, which displays the Programs sorted by full name. The highlighted cursor is initially positioned in this window. You can use the up and down cursor movement keys to move it through the list of Program objects. The top line of the screen displays the full name of the selected Program. The Attributes window (upper right window) displays all the attributes of the selected Program. The Process window (bottom window) displays the list of processes that are instances of the selected Program; that is, its associated Program executions. Alternatively, if this Program has not been executed, the message "No processes" is displayed. Should it not be possible to view all of the processes together, select this window by pressing , and use the up and down cursor movement keys to move the cursor through the list of processes. This window displays each process on a separate line, in three columns (the first column contains the process identifier, the second contains its state and the third contains the node on which the process is running). Press again to select the Program window. 9-12 Application Management Services Monitor 9.4 Views The command line at the bottom of the screen displays the available options. In the case of the Program view, menu options include jumping to another view, changing the cursor mode, quitting the Application Management Services Monitor, or switching between the Program window and the Process window, as follows: ___________________________________________________________ Option___________Command_____________Function______________ [ENTER] toggle key To move between windows Actors A To invoke Actor view aCtivities C To invoke Activity view pRocesses R To invoke Process view Nodes N To invoke Node view cursor-Mode M User Mode or Follow Updates Quit Q To exit Application Management Services _____________________________________Monitor_______________ 9.4.4 Process View This view has only one window and displays all existing processes, which are the Program executions associated to the Program objects defined in the Realm. When this view is called, it displays each process on a separate line, together with its process identifier, state and the name of the BASEstar Open Node on which the process is running. The top line of the screen displays the full name of the Program associated with the selected process (see Figure 9-7). 9-13 Application Management Services Monitor 9.4 Views Figure 9-7 Process View +------------------------------------------------------------------+ | PROGRAM: /program_example_1 | | | +------------------------------------------------------------------+ | 19606 RUNNING current_node | | 19593 RUNNING current_node | | 19642 RUNNING current_node | | 19632 RUNNING current_node | | | | | | | | | | | | | | | | | | | | | +------------------------------------------------------------------+ The command line at the bottom of the screen displays the available options. In the case of the process view, menu options include jumping to another view, changing the cursor mode, or quitting the Application Management Services Monitor, as follows: ___________________________________________________________ Option___________Command_____________Function______________ Actors A To invoke Actor view aCtivities C To invoke Activity view Programs P To invoke Program view Nodes N To invoke Node view cursor-Mode M User Mode or Follow Updates Quit Q To exit Application Management Services _____________________________________Monitor_______________ 9-14 Application Management Services Monitor 9.4 Views 9.4.5 Node View Figure 9-8 shows how the Node view displays all network Nodes known to Application Management Services. Figure 9-8 Node View +------------------------------------------------------------------+ | KNOWN NODES | | | +------------------------------------------------------------------+ | SABATO current_node E RUNNING | | | | | | | | | | | | | | | | | | | | | | | | | | | +------------------------------------------------------------------+ This view has only one window and displays Node information in four columns. It provides the following information: o The name of the Node (the physical name attribute value of the associated BASEstar Open Node). o The name of the BASEstar Open Node. o The value of the Node state attribute. The letter "E" represents Enabled and the letter "D" represents Disabled. o The implementation status of the Application Management Services server currently active on the node. There are four possible values: - IDLE Server not yet activated 9-15 Application Management Services Monitor 9.4 Views - STARTING Server starting up - RUNNING Server up - ABORTED Server was up, but went down under abnormal conditions The command line at the bottom of the screen displays the available options. In the case of the Node view, menu options include jumping to another view, changing the cursor mode, or quitting the Application Management Services Monitor, as follows: ___________________________________________________________ Option___________Command_____________Function______________ Actors A To invoke Actor view aCtivities C To invoke Activity view Programs P To invoke Program view pRocesses R To invoke Process view cursor-Mode M User Mode or Follow Updates Quit Q To exit Application Management Services _____________________________________Monitor_______________ 9-16 10 _________________________________________________________________ Log Services Features The Log Services collect and record information regarding general happenings and error conditions detected by the Node and Realm-specific components. A Log Services server process is activated on each Node, and performs the following functions: o Collects log records sent to it from the other Node- specific components and writes them to the Node log file. o Collects log records from the components specific to the Realms that have been started up on the Node and writes them to the Realm log file. The Log Services server creates a log file for each Realm that has been started up. The information collected in the log files is primarily intended to help Digital support personnel, but you can also use it for monitoring the behavior of and actions performed by your environment components. 10.1 Saving Copies of Log Files The Log Services operator interface consists of the commands shown in Table 10-1 (see Chapter 11 for a complete description). 10-1 Log Services Features 10.1 Saving Copies of Log Files Table_10-1_Log_Services_CLI_Commands_______________________ Command_Name________________Description____________________ OPEN LOG Swaps the contents of a log file working copy into a save copy. DISPLAY LOG Displays the contents of a log ____________________________file_working_copy._____________ You can swap the contents of a working copy log file into a save copy by using the OPEN LOG command which also empties up the log file working copy. The OPEN LOG command appends a user-specified string at the end of the just created save copy, and inserts the same string at the top of the emptied log file working copy. Working and save copies of the log files are assigned the following names, where N is a number that is assigned sequentially: o The name of the log file working copy for the current Node is BASESTARNODE.log, whereas the save copies have name BASESTARNODE_N.log. o The name of the working copy log file for a Realm log file is realm_name.log, whereas the save copies have name realm_name_N.log. 10.1.1 Log File Location On any started up Node, log files are stored under the following directory: $BSTR_WORK_ROOT/node/log 10.1.2 Purging Log Files All the log files that have been created on a Node, except the working copies, can be deleted by specifying the -c option when executing the bstr_node_start command for that Node. 10-2 Log Services Features 10.2 Log File Record Format 10.2 Log File Record Format Log files are ASCII files containing log records whose format is defined by BASEstar Open and consists of: o The sequence number associated with a log message generated by the Log Services server. This number is reset to 0 when the Log Services server is started up (that is, when the bstr_node_start command is executed), and is incremented by 1 for each message that is generated. A log message is written by the Log Services server to one log file. Thus, each message has a sequence number that does not depend on the log file to which is written and is unique for each message logged on that Node o The date and time when the log record has been written to the log file o The process identifier of the component that generated the log record o An identifier (see Table 10-2) that specifies the environment component that generated it o The text of the log record message Table_10-2_Log_File_Component_Identifier___________________ BASEstar_Open_Component____Identifier______________________ Node-Specific Environment Components __________(Started_Through_Environment_Commands)___________ Watchdog WATCHD WATCHLD Name Service LNSHM LNSSR (continued on next page) 10-3 Log Services Features 10.2 Log File Record Format Table_10-2_(Cont.)_Log_File_Component_Identifier___________ ___________________________________________________________ Realm-Specific Environment and Application Components ___________(Started_Through_Environment_Commands)__________ Communication Service CE CNS TCP_RCM Application Management AMS_SERVER Services servers Global Object Services GOM_SERVER servers Database Services servers DB Server PC Communication server PCS ___________________________________________________________ Realm-Specific Environment and Application Components (Started from Application ________Management_Services_or_Command_Interpreter)________ Event Services servers EVM_SERVER Packet Services servers MGM_SERVER Data & Device Services DDM_SERVER servers ___________________________________________________________ __________________Miscellaneous_Components_________________ CLI_instances______________CLI_BSTR________________________ Example 10-1 shows an example of a Node log file: Example 10-1 Node Log File Example (continued on next page) 10-4 Log Services Features 10.2 Log File Record Format Example 10-1 (Cont.) Node Log File Example 0000000 93/08/17 10:18:14 20245794 WATCHD: I-BSTR_S_COM_SOMETHINGFAILED: trc_initialize(WATCHD, NULL, TRC_PATH=NULL) returned 112704524. 0000001 93/08/17 10:18:15 20245794 WATCHD: S-BSTR_S_COM_START: Start (BASEStar Open 2.0 (Rev. 4, FT2), Aug 14 1993, 00:33:30) 0000002 93/08/17 10:18:32 2024479a LNSHM: S-BSTR_S_COM_START: Start (BASEStar Open 2.0 (Rev. 4, FT2), Aug 14 1993, 00:15:59) 0000003 93/08/17 10:18:32 2024479a LNSHM: I-BSTR_S_COM_SOMETHINGFAILED: trc_initialize(LNSHM, NULL, TRC_PATH=NULL) returned 112704524. 0000004 93/08/17 10:18:33 2024479a LNSHM: S-BSTR_S_COM_LNS_LOADEDCONF: Configuration: nspace=BSTR HMP=6100 SRP=6101 SH=BSTVMS ER=4 SH=NAXOS1 ER=16 0000005 93/08/17 10:18:34 2024479a LNSHM: I-BSTR_S_COM_LNS_HM_TRY_CONNECT: Host Manager @BSTVMS trying to connect to Server @BSTVMS 0000006 93/08/17 10:18:36 2024379c LNSSR: S-BSTR_S_COM_START: Start (BASEStar Open 2.0 (Rev. 4, FT2), Aug 14 1993, 00:25:31) 0000007 93/08/17 10:18:37 2024379c LNSSR: I-BSTR_S_COM_SOMETHINGFAILED: trc_initialize(LNSSR, NULL, TRC_PATH=NULL) returned 112704524. 0000008 93/08/17 10:18:38 2024379c LNSSR: S-BSTR_S_COM_LNS_LOADEDCONF: Configuration: nspace=BSTR HMP=6100 SRP=6101 SH=BSTVMS ER=4 SH=NAXOS1 ER=16 0000009 93/08/17 10:19:12 2024379c LNSSR: S-BSTR_S_COM_LNS_I_AM_MASTER: I am MASTER @BSTVMS SLAVE is @NAXOS1 (config.: ns=BSTR, master @BSTVMS slave @NAXOS1) 0000010 93/08/17 10:19:14 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_CONNECTED: Host Manager @BSTVMS (ns=BSTR) connected to Server @BSTVMS 0000011 93/08/17 10:19:14 2024379c LNSSR: I-BSTR_S_COM_LNS_HS_CHANGE: Watchdog status change notification: host 'BSTVMS' is now 'ALIVE' 0000012 93/08/17 10:21:36 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_CONNECTED: Host Manager @NAXOS1 (ns=BSTR) connected to Server @BSTVMS 0000013 93/08/17 10:21:36 2024379c LNSSR: I-BSTR_S_COM_LNS_HS_CHANGE: Watchdog status change notification: host 'NAXOS1' is now 'ALIVE' 0000014 93/08/17 10:21:44 2024379c LNSSR: S-BSTR_S_COM_LNS_BRAINDUMP_START: Brain-dump started (source @BSTVMS target @NAXOS1 namespace=BSTR) 0000015 93/08/17 10:22:03 2024379c LNSSR: S-BSTR_S_COM_LNS_BRAINDUMP_END: Brain-dump ended (source @BSTVMS target @NAXOS1) 0000016 93/08/17 10:22:11 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_CONNECTED: Host Manager @NAXOS2 (ns=BSTR) connected to Server @BSTVMS 0000017 93/08/17 10:22:12 2024379c LNSSR: I-BSTR_S_COM_LNS_HS_CHANGE: Watchdog status change notification: host 'NAXOS2' is now 'ALIVE' 0001974 93/08/25 08:24:37 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_DISCONNECTED: Host Manager @NAXOS2 (ns=BSTR) disconnected from Server @BSTVMS 0001979 93/08/26 09:07:59 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_CONNECTED: (continued on next page) 10-5 Log Services Features 10.2 Log File Record Format Example 10-1 (Cont.) Node Log File Example Host Manager @NAXOS2 (ns=BSTR) connected to Server @BSTVMS 0002043 93/08/26 14:18:52 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_DISCONNECTED: Host Manager @NAXOS2 (ns=BSTR) disconnected from Server @BSTVMS 0002044 93/08/26 14:19:35 2024379c LNSSR: I-BSTR_S_COM_LNS_HS_CHANGE: Watchdog status change notification: host 'NAXOS2' is now 'DEAD' 0002045 93/08/26 14:21:35 2024379c LNSSR: I-BSTR_S_COM_LNS_HS_CHANGE: Watchdog status change notification: host 'NAXOS2' is now 'ALIVE' 0002046 93/08/26 14:21:39 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_CONNECTED: Host Manager @NAXOS2 (ns=BSTR) connected to Server @BSTVMS 0002047 93/08/26 14:22:49 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_DISCONNECTED: Host Manager @NAXOS2 (ns=BSTR) disconnected from Server @BSTVMS 0002048 93/08/26 14:23:47 2024379c LNSSR: I-BSTR_S_COM_LNS_HS_CHANGE: Watchdog status change notification: host 'NAXOS2' is now 'DEAD' 0002049 93/08/26 14:24:18 2024379c LNSSR: I-BSTR_S_COM_LNS_HS_CHANGE: Watchdog status change notification: host 'NAXOS2' is now 'ALIVE' 0002050 93/08/26 14:24:26 2024379c LNSSR: S-BSTR_S_COM_LNS_HM_CONNECTED: Host Manager @NAXOS2 (ns=BSTR) connected to Server @BSTVMS Example 10-2 shows an example of a Realm log file: 10-6 Log Services Features 10.2 Log File Record Format Example 10-2 Realm Log File Example 0005939 93/09/13 12:58:01 21c56abd CE: S-BSTR_S_COM_START: Start (BASEStar Open 2.0 (Rev. 4, FT2), Aug 14 1993, 00:13:30) 0005940 93/09/13 12:58:01 21c56abd CE: S-BSTR_S_COM_START: Start (BASEStar Open 2.0 (Rev. 4, FT2), Aug 14 1993, 00:13:30) 0005955 93/09/13 12:58:06 21c592c5 CNS: S-BSTR_S_COM_START: Start 0005970 93/09/13 12:58:27 21c59308 GOM_SERVER: I-BSTR_S_GOM_SERVER_START: GOM Server starting up 0005972 93/09/13 12:58:35 21c59308 GOM_SERVER: I-BSTR_S_GOM_SNP_LOAD: Load snapshot file: objects=DATATYPE; access_key=SNAPSHOT; database=BSTR$SNAPSHOT; version=1 0005974 93/09/13 12:58:36 21c59308 GOM_SERVER: I-BSTR_S_GOM_SNP_LOAD: Load snapshot file: objects=DOMAIN; access_key=SNAPSHOT; database=BSTR$SNAPSHOT; version=1 0005976 93/09/13 12:58:36 21c59308 GOM_SERVER: I-BSTR_S_GOM_SNP_LOAD: Load snapshot file: objects=DEVICE; access_key=SNAPSHOT; database=BSTR$SNAPSHOT; version=1 0005991 93/09/13 12:58:41 21c59318 TCP_RCM: S-BSTR_S_COM_START: Start (BASEStar Open 2.0 (Rev. 4, FT2), Aug 14 1993, 00:36:52) 0005992 93/09/13 12:58:41 21c59318 TCP_RCM: I-BSTR_S_COM_SOMETHINGFAILED: trc_initialize(TCP_RCM, NULL, TRC_PATH=NULL) returned 112704524. 0006008 93/09/13 12:59:06 21c59320 AMS_SERVER: I-BSTR_S_AMS_AMSSTART: AMS SERVER starting for realm 'NESTLE (BASEStar Open 2.0 (Rev. 4, FT2), Aug 14 1993, 00:46:48)' 0006022 93/09/13 12:59:17 21c59320 AMS_SERVER: I-BSTR_S_AMS_CLILOAD: CONFIGURATION LOAD request: -t SNAPSHOT -a BSTR$SNAPSHOT -v 1 0006023 93/09/13 12:59:18 21c59320 AMS_SERVER: W-BSTR_S_AMS_SNP_NOT_FOUND: Snapshot file not found: Access Key 'BSTR$SNAPSHOT'; Db 'SNAPSHOT' Version '1' 0006024 93/09/13 12:59:19 21c59320 AMS_SERVER: I-BSTR_S_AMS_READY: AMS Server ready to work 0006267 93/09/13 13:07:11 21c59320 AMS_SERVER: I-BSTR_S_AMS_CLILOAD: CONFIGURATION LOAD request: -t SNAPSHOT -a BSTR$SNAPSHOT -v 1 0007620 93/09/13 13:26:56 21c59320 AMS_SERVER: I-BSTR_S_AMS_PRCCREA: Process 21c5909c created on node 'BSTVMS'; program '/nestle/PRG_EVM_SERVER' 0007636 93/09/13 13:27:11 21c5909c EVM_SERVER: Program '/nestle/PRG_EVM_SERVER' running with AMS 0007637 93/09/13 13:27:11 21c5909c EVM_SERVER: Program '/nestle/PRG_EVM_SERVER' starting 0007638 93/09/13 13:27:15 21c5909c EVM_SERVER: (continued on next page) 10-7 Log Services Features 10.2 Log File Record Format Example 10-2 (Cont.) Realm Log File Example Start Activity '/nestle/EVM_PRODUCTION' 0007639 93/09/13 13:27:17 21c5909c EVM_SERVER: Activity '/nestle/EVM_PRODUCTION' beginning 0007640 93/09/13 13:27:19 21c5909c EVM_SERVER: Activity '/nestle/EVM_PRODUCTION' ready to init 0007641 93/09/13 13:27:20 21c5909c EVM_SERVER: Activity '/nestle/EVM_PRODUCTION' enter init phase 0007642 93/09/13 13:27:21 21c5909c EVM_SERVER: Activity '/nestle/EVM_PRODUCTION' ready to start 0007643 93/09/13 13:27:22 21c5909c EVM_SERVER: Activity '/nestle/EVM_PRODUCTION' enter start phase 0010206 93/09/20 09:39:09 21c59320 AMS_SERVER: W-BSTR_S_AMS_SHUT_REQUEST: Shutdown request 0010207 93/09/20 09:39:10 21c59320 AMS_SERVER: W-BSTR_S_AMS_SHUTATTMSG: Shutdown attention message received 0010208 93/09/20 09:39:10 21c59320 AMS_SERVER: I-BSTR_S_AMS_AMSSHUT: AMS SERVER shutting 0010209 93/09/20 09:39:14 21c59320 AMS_SERVER: W-BSTR_S_AMS_PRCEXIT: Process 21c5909c terminated with exit status: %SYSTEM-S-NORMAL, normal successful completion 0010214 93/09/20 09:39:20 21c59308 GOM_SERVER: I-BSTR_S_GOM_CLNTSHUT: Client shutdown: client_id=1 0010215 93/09/20 09:39:32 21c59308 GOM_SERVER: I-BSTR_S_GOM_SERVER_SHUT: GOM Server shutting down 0010217 93/09/20 09:39:44 21c592c5 CNS: S-BSTR_S_COM_END: End 0010221 93/09/20 09:39:47 21c56abd CE: S-BSTR_S_COM_END: End 0010222 93/09/20 09:39:48 21c59479 DB Server: DB server exiting 10.2.1 Displaying Log Files The log files are ASCII files that can be displayed by using any platform-dependent tool or editor. You must perform different operations depending on whether you want to display a working copy or save copy of a log file. See Section 10.1 to know about where log files are stored and about log file naming conventions. 10-8 Log Services Features 10.2 Log File Record Format 10.2.1.1 Displaying a Save Copy To display a save copy of a log file you can use any command or utility you wish that can be used to display an ASCII file. 10.2.1.2 Displaying a Working Copy The working copy log files are opened by the Log Services server and thus they cannot be displayed by using the standard tools when the Node is started up. Thus, the DISPLAY LOG command has been provided to allow the display of log file working copies. This command also can display the last lines of a log file automatically refreshing them as soon as a new record is inserted in the displayed log file. This allows you to monitor record insertion in the selected log file. 10.3 Log Services Server Activities The Log Services server process is a Node-specific component which is started up when the bstr_node_start command is executed. Actually, it is the first process to be started up, so the other Nodes find it already available. In its turn, the Log Services server logs some record information regarding general happenings and unrecoverable errors detected during its own operation in the platform- dependent system log. For example, as soon as the Log Services server is started up, it logs the following message to the system log file: Jul 14 11:35:12 localhost: 21124 BASESTAR LOG: Server started, output file: ./log_server.out, log directory: ./ 10-9 11 _________________________________________________________________ Log Services Command Reference 11-1 DISPLAY LOG _________________________________________________________________ DISPLAY LOG Displays the contents of a log file working copy. Format DISPLAY LOG Command Qualifier Default [-REALM realm_name] Current Realm [-NODE] Current Node [-HEAD head_lines] 10 [-TAIL tail_lines] 10 [-CONTINUE] Description The DISPLAY LOG command allows you to display records from both Realm and Node log file working copies. The -REALM and -NODE qualifiers are mutually exclusive: o If you specify the -REALM qualifier, the realm_name argument indicates the name of the Realm. o If you specify the -NODE qualifier, you select to display the log file for the node on which you are operating. o If you do not specify either the -REALM or the -NODE qualifier, the value of the -NODE qualifier is assumed by default. If you provide a value for the head_lines (tail_lines) argument, the DISPLAY LOG command displays the requested lines starting from the top (bottom) of the selected log file. If you specify both the -CONTINUE and -TAIL qualifiers, the DISPLAY LOG command displays the last tail_lines and refresh them automatically as soon as a new record is inserted in the displayed log file. This allows you to monitor record insertion in the selected log file. To terminate execution of a command, press / 11-2 DISPLAY LOG Qualifiers -REALM realm_name The realm_name argument specifies the local name of the Realm whose log file you want to display. The specified Realm must have been started up on the current Node. This qualifier and the -NODE qualifier are mutually exclusive. -NODE Directs the DISPLAY LOG command to display the log file of the current Node. This qualifier and the -NODE qualifier are mutually exclusive. If neither the -REALM nor the -NODE qualifier is specified, the value of the -NODE qualifier is assumed by default. -HEAD head_lines Directs the command to display the number of lines specified by the head_lines argument starting from the top of the selected log file. The -TAIL and -HEAD qualifiers are mutually exclusive. -TAIL tail_lines Directs the command to display the number of lines specified by the tail_lines argument starting from the bottom of the selected log file. The -TAIL and -HEAD qualifiers are mutually exclusive. -CONTINUE Directs the DISPLAY LOG command to display the last tail_ lines and to refresh them as soon as a new record is inserted in the displayed log file. This allows you to monitor record insertion in the selected log file. When specified, the -CONTINUE qualifier must be specified together with the -TAIL qualifier. 11-3 OPEN LOG _________________________________________________________________ OPEN LOG Swaps the contents of a log file working copy into a save copy. Format OPEN LOG Command Qualifier Default [-REALM realm_name] Current Realm [-NODE] Current Node [-DESCRIPTION string] No Description Description The OPEN LOG command performs the following actions for the current Node or the specified Realm: 1. Closes the working copy log file and renames it into a save copy. 2. Appends the string specified by the -DESCRIPTION qualifier at the end of the just created save copy. 3. Creates and opens a new empty working copy log file and inserts the same string specified by the -DESCRIPTION qualifier. The -REALM and -NODE qualifiers are mutually exclusive. If neither the -REALM nor the -NODE qualifier is specified, the -NODE qualifier is assumed by default. Assuming that N is a progressively assigned number: o The name of the log file for the current Node is BASESTARNODE.log, while save copies have name BASESTARNODE_N.log. o The name of the log file for a Realm log file is realm_ name.log, while save copies have name BASESTARNODE- N.log. Log files are stored under the following directory: $BSTR_WORK_ROOT/node/log 11-4 OPEN LOG Qualifiers -REALM realm_name Tells the OPEN LOG command to operate on the log file working copy of the realm_name. If this qualifier is not specified, the Realm specified by the BSTR_REALM global variable is assumed by default. The specified Realm must have been started up on the current Node. This qualifier and the -NODE qualifier are mutually exclusive. -NODE Tells the OPEN LOG command to operate on the log file working copy of the current Node. This qualifier and the -NODE qualifier are mutually exclusive. If neither the -REALM nor the -NODE qualifier is specified, the -NODE qualifier is assumed by default. -DESCRIPTION string Is user-defined information that is appended to the end of a save copy and inserted on the top of the working copy log file. The description need not conform to any format and must be enclosed between quotation marks (" "). The string argument is a string of maximum 128 characters. 11-5 A _________________________________________________________________ Files Installed by BASEstar Open Server This appendix lists the files that the BASEstar Open Server installation procedure creates on Digital UNIX and HP-UX systems. A.1 Digital UNIX Systems A.1.1 Directories Installed by the BSTBASE300 Subset Table A-1 describes the directories installed by the BSTBASE300 subset. Table_A-1_Directories_Installed_by_the_BSTBASE300_Subset_________ Directory_____________________Description________________________ /usr/opt/bstbase300/bin Executable programs distributed with BASEstar Open (for example, Server and CLI) /usr/opt/bstbase300/doc Files constituting the product documentation addendum (for example, the Release Notes) /usr/opt/bstbase300/include Include files. For example, bstr.h /usr/opt/bstbase300/lib Shared libraries and message catalogues. For example, the libbstr.so and libbstr_cma.so API procedure libraries and the NLS message catalogues (see environ(5int) for further information) (continued on next page) A-1 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems Table_A-1_(Cont.)_Directories_Installed_by_the_BSTBASE300_Subset_ Directory_____________________Description________________________ /usr/opt/bstbase300/man Online manual pages for BASEstar Open /usr/opt/bstbase300/examples Source code of the programming /api examples distributed with BASEstar Open /usr/opt/bstbase300/ivp Installation Verification Procedures (IVP) files /usr/var/opt/bstbase300/etc Configuration files and programs or shell scripts for BASEstar Open ______________________________environment_management_____________ A.1.2 Files Installed by the BSTBASE300 Subset The BSTBASE300 subset installs the following files: ./usr/opt/bstbase300/bin/ams_mon ./usr/opt/bstbase300/bin/ams_server ./usr/opt/bstbase300/bin/ams_debug ./usr/opt/bstbase300/bin/bstr_licence_check ./usr/opt/bstbase300/bin/bstr_realm_setup_node ./usr/opt/bstbase300/bin/bstr_realm_shut_node ./usr/opt/bstbase300/bin/bstr_realm_start_node ./usr/opt/bstbase300/bin/bstr_realm_unset_node ./usr/opt/bstbase300/bin/bstr_realm_check_env ./usr/opt/bstbase300/bin/bstr_env_show ./usr/opt/bstbase300/bin/internal/env_show ./usr/opt/bstbase300/bin/internal/get_path ./usr/opt/bstbase300/bin/internal/bstr__id ./usr/opt/bstbase300/bin/internal/bstr__version ./usr/opt/bstbase300/bin/internal/bstr__access ./usr/opt/bstbase300/bin/internal/bstr__echo ./usr/opt/bstbase300/bin/internal/bstr_calldbx ./usr/opt/bstbase300/bin/internal/waitpid ./usr/opt/bstbase300/bin/bstr_utl_tgen ./usr/opt/bstbase300/bin/bstr_mon ./usr/opt/bstbase300/bin/bstr_realm_trace_node ./usr/opt/bstbase300/bin/cli_bstr ./usr/opt/bstbase300/bin/cli_trc ./usr/opt/bstbase300/bin/bstr_realm_setup_db.oracle ./usr/opt/bstbase300/bin/bstr_realm_unset_db.oracle A-2 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./usr/opt/bstbase300/bin/ce ./usr/opt/bstbase300/bin/bstr_realm_shut_db.oracle ./usr/opt/bstbase300/bin/bstr_realm_start_db.oracle ./usr/opt/bstbase300/bin/cnf_db_init.oracle ./usr/opt/bstbase300/bin/cnf_dbserver.oracle ./usr/opt/bstbase300/bin/attention_msg ./usr/opt/bstbase300/bin/cns ./usr/opt/bstbase300/bin/com_choose_instf ./usr/opt/bstbase300/bin/com_choose_ceconf ./usr/opt/bstbase300/bin/com_control ./usr/opt/bstbase300/bin/com_customize ./usr/opt/bstbase300/bin/com_daemon_start ./usr/opt/bstbase300/bin/com_edit_param ./usr/opt/bstbase300/bin/com_get_param ./usr/opt/bstbase300/bin/com_is_alive ./usr/opt/bstbase300/bin/com_show_net ./usr/opt/bstbase300/bin/com_lns_mon ./usr/opt/bstbase300/bin/lns_event_mgmt ./usr/opt/bstbase300/bin/com_start_lns ./usr/opt/bstbase300/bin/com_start_watchdog ./usr/opt/bstbase300/bin/com_sync_lns ./usr/opt/bstbase300/bin/com_sync_watchdog ./usr/opt/bstbase300/bin/lnshm ./usr/opt/bstbase300/bin/lnshm_control ./usr/opt/bstbase300/bin/lnssr ./usr/opt/bstbase300/bin/rcmtcp ./usr/opt/bstbase300/bin/watchd ./usr/opt/bstbase300/bin/watchd_control ./usr/opt/bstbase300/bin/lcpisrv ./usr/opt/bstbase300/bin/ddm_server ./usr/opt/bstbase300/bin/evm_server ./usr/opt/bstbase300/bin/gom_server ./usr/opt/bstbase300/bin/log_server ./usr/opt/bstbase300/bin/logtool ./usr/opt/bstbase300/bin/logcntrl ./usr/opt/bstbase300/bin/mgm_server ./usr/opt/bstbase300/lib/libbstrcma.so ./usr/opt/bstbase300/lib/libbstr.so ./usr/opt/bstbase300/lib/bstr_msg.cat ./usr/opt/bstbase300/lib/cli.syntax ./usr/opt/bstbase300/lib/trc.syntax ./usr/opt/bstbase300/lib/bstr_cli_cat.cat ./usr/opt/bstbase300/lib/cli/man_0 A-3 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./usr/opt/bstbase300/lib/cli/man_10 ./usr/opt/bstbase300/lib/cli/man_100 ./usr/opt/bstbase300/lib/cli/man_103 ./usr/opt/bstbase300/lib/cli/man_105 ./usr/opt/bstbase300/lib/cli/man_106 ./usr/opt/bstbase300/lib/cli/man_107 ./usr/opt/bstbase300/lib/cli/man_108 ./usr/opt/bstbase300/lib/cli/man_109 ./usr/opt/bstbase300/lib/cli/man_11 ./usr/opt/bstbase300/lib/cli/man_110 ./usr/opt/bstbase300/lib/cli/man_111 ./usr/opt/bstbase300/lib/cli/man_112 ./usr/opt/bstbase300/lib/cli/man_113 ./usr/opt/bstbase300/lib/cli/man_114 ./usr/opt/bstbase300/lib/cli/man_115 ./usr/opt/bstbase300/lib/cli/man_118 ./usr/opt/bstbase300/lib/cli/man_119 ./usr/opt/bstbase300/lib/cli/man_12 ./usr/opt/bstbase300/lib/cli/man_120 ./usr/opt/bstbase300/lib/cli/man_123 ./usr/opt/bstbase300/lib/cli/man_124 ./usr/opt/bstbase300/lib/cli/man_127 ./usr/opt/bstbase300/lib/cli/man_128 ./usr/opt/bstbase300/lib/cli/man_131 ./usr/opt/bstbase300/lib/cli/man_132 ./usr/opt/bstbase300/lib/cli/man_135 ./usr/opt/bstbase300/lib/cli/man_136 ./usr/opt/bstbase300/lib/cli/man_137 ./usr/opt/bstbase300/lib/cli/man_138 ./usr/opt/bstbase300/lib/cli/man_141 ./usr/opt/bstbase300/lib/cli/man_142 ./usr/opt/bstbase300/lib/cli/man_143 ./usr/opt/bstbase300/lib/cli/man_144 ./usr/opt/bstbase300/lib/cli/man_147 ./usr/opt/bstbase300/lib/cli/man_148 ./usr/opt/bstbase300/lib/cli/man_149 ./usr/opt/bstbase300/lib/cli/man_15 ./usr/opt/bstbase300/lib/cli/man_150 ./usr/opt/bstbase300/lib/cli/man_151 ./usr/opt/bstbase300/lib/cli/man_152 ./usr/opt/bstbase300/lib/cli/man_155 ./usr/opt/bstbase300/lib/cli/man_157 ./usr/opt/bstbase300/lib/cli/man_158 A-4 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./usr/opt/bstbase300/lib/cli/man_159 ./usr/opt/bstbase300/lib/cli/man_160 ./usr/opt/bstbase300/lib/cli/man_162 ./usr/opt/bstbase300/lib/cli/man_164 ./usr/opt/bstbase300/lib/cli/man_166 ./usr/opt/bstbase300/lib/cli/man_168 ./usr/opt/bstbase300/lib/cli/man_169 ./usr/opt/bstbase300/lib/cli/man_171 ./usr/opt/bstbase300/lib/cli/man_172 ./usr/opt/bstbase300/lib/cli/man_173 ./usr/opt/bstbase300/lib/cli/man_174 ./usr/opt/bstbase300/lib/cli/man_175 ./usr/opt/bstbase300/lib/cli/man_176 ./usr/opt/bstbase300/lib/cli/man_177 ./usr/opt/bstbase300/lib/cli/man_178 ./usr/opt/bstbase300/lib/cli/man_179 ./usr/opt/bstbase300/lib/cli/man_180 ./usr/opt/bstbase300/lib/cli/man_181 ./usr/opt/bstbase300/lib/cli/man_184 ./usr/opt/bstbase300/lib/cli/man_188 ./usr/opt/bstbase300/lib/cli/man_189 ./usr/opt/bstbase300/lib/cli/man_190 ./usr/opt/bstbase300/lib/cli/man_191 ./usr/opt/bstbase300/lib/cli/man_192 ./usr/opt/bstbase300/lib/cli/man_196 ./usr/opt/bstbase300/lib/cli/man_197 ./usr/opt/bstbase300/lib/cli/man_198 ./usr/opt/bstbase300/lib/cli/man_199 ./usr/opt/bstbase300/lib/cli/man_200 ./usr/opt/bstbase300/lib/cli/man_201 ./usr/opt/bstbase300/lib/cli/man_202 ./usr/opt/bstbase300/lib/cli/man_203 ./usr/opt/bstbase300/lib/cli/man_204 ./usr/opt/bstbase300/lib/cli/man_205 ./usr/opt/bstbase300/lib/cli/man_206 ./usr/opt/bstbase300/lib/cli/man_207 ./usr/opt/bstbase300/lib/cli/man_208 ./usr/opt/bstbase300/lib/cli/man_209 ./usr/opt/bstbase300/lib/cli/man_210 ./usr/opt/bstbase300/lib/cli/man_211 ./usr/opt/bstbase300/lib/cli/man_212 ./usr/opt/bstbase300/lib/cli/man_213 ./usr/opt/bstbase300/lib/cli/man_214 A-5 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./usr/opt/bstbase300/lib/cli/man_22 ./usr/opt/bstbase300/lib/cli/man_25 ./usr/opt/bstbase300/lib/cli/man_27 ./usr/opt/bstbase300/lib/cli/man_3 ./usr/opt/bstbase300/lib/cli/man_30 ./usr/opt/bstbase300/lib/cli/man_32 ./usr/opt/bstbase300/lib/cli/man_33 ./usr/opt/bstbase300/lib/cli/man_34 ./usr/opt/bstbase300/lib/cli/man_35 ./usr/opt/bstbase300/lib/cli/man_36 ./usr/opt/bstbase300/lib/cli/man_39 ./usr/opt/bstbase300/lib/cli/man_41 ./usr/opt/bstbase300/lib/cli/man_44 ./usr/opt/bstbase300/lib/cli/man_46 ./usr/opt/bstbase300/lib/cli/man_47 ./usr/opt/bstbase300/lib/cli/man_48 ./usr/opt/bstbase300/lib/cli/man_5 ./usr/opt/bstbase300/lib/cli/man_51 ./usr/opt/bstbase300/lib/cli/man_53 ./usr/opt/bstbase300/lib/cli/man_54 ./usr/opt/bstbase300/lib/cli/man_55 ./usr/opt/bstbase300/lib/cli/man_56 ./usr/opt/bstbase300/lib/cli/man_57 ./usr/opt/bstbase300/lib/cli/man_58 ./usr/opt/bstbase300/lib/cli/man_59 ./usr/opt/bstbase300/lib/cli/man_6 ./usr/opt/bstbase300/lib/cli/man_62 ./usr/opt/bstbase300/lib/cli/man_64 ./usr/opt/bstbase300/lib/cli/man_65 ./usr/opt/bstbase300/lib/cli/man_66 ./usr/opt/bstbase300/lib/cli/man_67 ./usr/opt/bstbase300/lib/cli/man_68 ./usr/opt/bstbase300/lib/cli/man_69 ./usr/opt/bstbase300/lib/cli/man_7 ./usr/opt/bstbase300/lib/cli/man_70 ./usr/opt/bstbase300/lib/cli/man_71 ./usr/opt/bstbase300/lib/cli/man_74 ./usr/opt/bstbase300/lib/cli/man_76 ./usr/opt/bstbase300/lib/cli/man_77 ./usr/opt/bstbase300/lib/cli/man_78 ./usr/opt/bstbase300/lib/cli/man_79 ./usr/opt/bstbase300/lib/cli/man_8 ./usr/opt/bstbase300/lib/cli/man_80 A-6 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./usr/opt/bstbase300/lib/cli/man_81 ./usr/opt/bstbase300/lib/cli/man_84 ./usr/opt/bstbase300/lib/cli/man_85 ./usr/opt/bstbase300/lib/cli/man_86 ./usr/opt/bstbase300/lib/cli/man_87 ./usr/opt/bstbase300/lib/cli/man_9 ./usr/opt/bstbase300/lib/cli/man_90 ./usr/opt/bstbase300/lib/cli/man_92 ./usr/opt/bstbase300/lib/cli/man_95 ./usr/opt/bstbase300/lib/cli/man_97 ./usr/opt/bstbase300/lib/cli/man_98 ./usr/opt/bstbase300/lib/cli/man_99 ./usr/opt/bstbase300/lib/cli/man_990 ./usr/opt/bstbase300/lib/cli/man_991 ./usr/opt/bstbase300/lib/cli/man_992 ./usr/opt/bstbase300/lib/cnf_tables.sql.oracle ./usr/opt/bstbase300/lib/cnf_indexes.sql.oracle ./usr/opt/bstbase300/lib/cnf_grants.sql ./usr/opt/bstbase300/lib/cnf_views.sql ./usr/opt/bstbase300/lib/libbstr.a_ ./usr/opt/bstbase300/lib/libbstrcma.a_ ./usr/opt/bstbase300/include/bstrstat.h_ ./usr/opt/bstbase300/include/bstrpub.h_ ./usr/opt/bstbase300/include/bstrppb.h_ ./usr/opt/bstbase300/include/bstrmsgl.h ./usr/opt/bstbase300/include/trlib.h_ ./usr/opt/bstbase300/include/bstr.h_ ./usr/opt/bstbase300/include/bstrmsg.h_ ./usr/opt/bstbase300/doc/relnotes.ps ./usr/opt/bstbase300/doc/relnotes.txt ./usr/opt/bstbase300/ivp/bstr_ivp ./usr/opt/bstbase300/ivp/bstr_ivp_obj.cli ./usr/opt/bstbase300/ivp/bstr_ivp_show.cli ./usr/opt/bstbase300/ivp/bstr_ivp_types.cli ./usr/opt/bstbase300/ivp/bstr_ivp_node_setup.inp ./usr/opt/bstbase300/ivp/snapshot_dir.tar ./usr/opt/bstbase300/ivp/bstr_ivp_kit_list ./usr/opt/bstbase300/ivp/bstr_ivp_show.cmp ./var/opt/bstbase300/etc/realm_startup/cleanup_ams.sh ./var/opt/bstbase300/etc/realm_startup/start10_ams.sh ./var/opt/bstbase300/etc/realm_startup/sync10_ams.sh ./var/opt/bstbase300/etc/realm_startup/clean10_ams.sh ./var/opt/bstbase300/etc/realm_startup/cleanup_fdbd.sh A-7 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./var/opt/bstbase300/etc/realm_startup/cleanup_tmpd.sh ./var/opt/bstbase300/etc/realm_startup/cleanup_db.sh ./var/opt/bstbase300/etc/realm_startup/start20_com.sh ./var/opt/bstbase300/etc/realm_startup/check_com.sh ./var/opt/bstbase300/etc/realm_startup/clean00_com.sh ./var/opt/bstbase300/etc/realm_startup/start00_com.sh ./var/opt/bstbase300/etc/realm_startup/sync00_com.sh ./var/opt/bstbase300/etc/realm_startup/cleanup_gom.sh ./var/opt/bstbase300/etc/realm_startup/start05_gom.sh ./var/opt/bstbase300/etc/realm_startup/sync05_gom.sh ./var/opt/bstbase300/etc/realm_startup/clean05_gom.sh ./var/opt/bstbase300/etc/realm_shutdown/shut10_ams.sh ./var/opt/bstbase300/etc/realm_shutdown/shut20_com.sh ./var/opt/bstbase300/etc/realm_shutdown/shut00_com.sh ./var/opt/bstbase300/etc/realm_shutdown/shut05_gom.sh ./var/opt/bstbase300/etc/bstbaseboot.sh ./var/opt/bstbase300/etc/bstr_ping ./var/opt/bstbase300/etc/host_startup/cleanlog.sh ./var/opt/bstbase300/etc/host_startup/cleanup_fdbd.sh ./var/opt/bstbase300/etc/host_startup/cleanup_tmpd.sh ./var/opt/bstbase300/etc/host_startup/start20_db.sh.oracle ./var/opt/bstbase300/etc/host_startup/cleanup_com.sh ./var/opt/bstbase300/etc/host_startup/check_com.sh ./var/opt/bstbase300/etc/host_startup/clean01_com.sh ./var/opt/bstbase300/etc/host_startup/start01_com.sh ./var/opt/bstbase300/etc/host_startup/sync01_com.sh ./var/opt/bstbase300/etc/host_startup/clean02_com.sh ./var/opt/bstbase300/etc/host_startup/start02_com.sh ./var/opt/bstbase300/etc/host_startup/sync02_com.sh ./var/opt/bstbase300/etc/host_startup/start03_com.sh ./var/opt/bstbase300/etc/host_startup/start00_log.sh ./var/opt/bstbase300/etc/host_startup/sync00_log.sh ./var/opt/bstbase300/etc/host_startup/clean00_log.sh ./var/opt/bstbase300/etc/bstr_node_setup ./var/opt/bstbase300/etc/bstr_node_shut ./var/opt/bstbase300/etc/bstr_node_start ./var/opt/bstbase300/etc/bstr_node_unset ./var/opt/bstbase300/etc/.exrc ./var/opt/bstbase300/etc/bstr_node_setup_db.oracle ./var/opt/bstbase300/etc/bstr_node_unset_db.oracle ./var/opt/bstbase300/etc/db_parameters.template.oracle ./var/opt/bstbase300/etc/host_shutdown/shut20_db.sh.oracle ./var/opt/bstbase300/etc/host_shutdown/shut07_com.sh A-8 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./var/opt/bstbase300/etc/host_shutdown/shut08_com.sh ./var/opt/bstbase300/etc/host_shutdown/shut09_com.sh ./var/opt/bstbase300/etc/host_shutdown/shut00_log.sh ./var/opt/bstbase300/etc/ce_conf.template ./var/opt/bstbase300/etc/installation_file.template ./var/opt/bstbase300/etc/lcpi_conf.template ./var/opt/bstbase300/etc/lns.conf.template ./usr/opt/bstman300/man/man1/bstr_env_show.1 ./usr/opt/bstman300/man/man1/bstr_node_setup.1 ./usr/opt/bstman300/man/man1/bstr_node_shut.1 ./usr/opt/bstman300/man/man1/bstr_node_start.1 ./usr/opt/bstman300/man/man1/bstr_node_unset.1 ./usr/opt/bstman300/man/man1/bstr_realm_check_env.1 ./usr/opt/bstman300/man/man1/bstr_realm_remake_db.1 ./usr/opt/bstman300/man/man1/bstr_realm_setup_db.1 ./usr/opt/bstman300/man/man1/bstr_realm_setup_node.1 ./usr/opt/bstman300/man/man1/bstr_realm_shut_db.1 ./usr/opt/bstman300/man/man1/bstr_realm_shut_node.1 ./usr/opt/bstman300/man/man1/bstr_realm_start_db.1 ./usr/opt/bstman300/man/man1/bstr_realm_start_node.1 ./usr/opt/bstman300/man/man1/bstr_realm_unset_db.1 ./usr/opt/bstman300/man/man1/bstr_realm_unset_node.1 ./usr/opt/bstman300/man/man3/bstr_activity_begin.3 ./usr/opt/bstman300/man/man3/bstr_activity_break.3 ./usr/opt/bstman300/man/man3/bstr_activity_end.3 ./usr/opt/bstman300/man/man3/bstr_activity_get_info.3 ./usr/opt/bstman300/man/man3/bstr_actor_execute.3 ./usr/opt/bstman300/man/man3/bstr_actor_get_info.3 ./usr/opt/bstman300/man/man3/bstr_actor_resume.3 ./usr/opt/bstman300/man/man3/bstr_actor_suspend.3 ./usr/opt/bstman300/man/man3/bstr_actor_terminate.3 ./usr/opt/bstman300/man/man3/bstr_asynchronous_request_wait.3 ./usr/opt/bstman300/man/man3/bstr_collection_loop.3 ./usr/opt/bstman300/man/man3/bstr_composite_loop.3 ./usr/opt/bstman300/man/man3/bstr_context_get_default.3 ./usr/opt/bstman300/man/man3/bstr_context_set_default.3 ./usr/opt/bstman300/man/man3/bstr_finish.3 ./usr/opt/bstman300/man/man3/bstr_data_point_get_cached_val.3 ./usr/opt/bstman300/man/man3/bstr_data_point_get_value.3 ./usr/opt/bstman300/man/man3/bstr_data_point_link.3 ./usr/opt/bstman300/man/man3/bstr_data_point_lock.3 ./usr/opt/bstman300/man/man3/bstr_data_point_put_value.3 ./usr/opt/bstman300/man/man3/bstr_data_point_reset_cache.3 A-9 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./usr/opt/bstman300/man/man3/bstr_data_point_unlink.3 ./usr/opt/bstman300/man/man3/bstr_data_point_unlock.3 ./usr/opt/bstman300/man/man3/bstr_database_get_scope.3 ./usr/opt/bstman300/man/man3/bstr_database_set_scope.3 ./usr/opt/bstman300/man/man3/bstr_enbox_connect.3 ./usr/opt/bstman300/man/man3/bstr_enbox_disconnect.3 ./usr/opt/bstman300/man/man3/bstr_enbox_get_info.3 ./usr/opt/bstman300/man/man3/bstr_enbox_receive_notification.3 ./usr/opt/bstman300/man/man3/bstr_error_stack_allocate.3 ./usr/opt/bstman300/man/man3/bstr_error_stack_clear.3 ./usr/opt/bstman300/man/man3/bstr_error_stack_free.3 ./usr/opt/bstman300/man/man3/bstr_error_stack_pop.3 ./usr/opt/bstman300/man/man3/bstr_error_stack_push.3 ./usr/opt/bstman300/man/man3/bstr_event_add_subscription.3 ./usr/opt/bstman300/man/man3/bstr_event_declare.3 ./usr/opt/bstman300/man/man3/bstr_event_disable_subscription.3 ./usr/opt/bstman300/man/man3/bstr_event_enable_subscription.3 ./usr/opt/bstman300/man/man3/bstr_event_get_subscriptions.3 ./usr/opt/bstman300/man/man3/bstr_event_notification_discard.3 ./usr/opt/bstman300/man/man3/bstr_event_remove_subscription.3 ./usr/opt/bstman300/man/man3/bstr_get_message.3 ./usr/opt/bstman300/man/man3/bstr_get_time.3 ./usr/opt/bstman300/man/man3/bstr_get_object_type_info.3 ./usr/opt/bstman300/man/man3/bstr_initialize.3 ./usr/opt/bstman300/man/man3/bstr_object_create.3 ./usr/opt/bstman300/man/man3/bstr_object_delete.3 ./usr/opt/bstman300/man/man3/bstr_object_disable_statistics.3 ./usr/opt/bstman300/man/man3/bstr_object_enable_statistics.3 ./usr/opt/bstman300/man/man3/bstr_object_get_attributes.3 ./usr/opt/bstman300/man/man3/bstr_object_get_statistics.3 ./usr/opt/bstman300/man/man3/bstr_object_get_status.3 ./usr/opt/bstman300/man/man3/bstr_object_reset_statistics.3 ./usr/opt/bstman300/man/man3/bstr_object_set_attributes.3 ./usr/opt/bstman300/man/man3/bstr_packet_notification_discard.3 ./usr/opt/bstman300/man/man3/bstr_port_connect.3 ./usr/opt/bstman300/man/man3/bstr_port_disconnect.3 ./usr/opt/bstman300/man/man3/bstr_port_get_info.3 ./usr/opt/bstman300/man/man3/bstr_port_receive_packet.3 ./usr/opt/bstman300/man/man3/bstr_port_reply_packet.3 ./usr/opt/bstman300/man/man3/bstr_port_send_packet.3 ./usr/opt/bstman300/man/man3/bstr_program_receive_request.3 ./usr/opt/bstman300/man/man3/bstr_realm_loop.3 ./usr/opt/bstman300/man/man3/bstr_reference_copy.3 A-10 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems ./usr/opt/bstman300/man/man3/bstr_reference_get_info.3 ./usr/opt/bstman300/man/man3/bstr_reference_recover.3 ./usr/opt/bstman300/man/man3/bstr_reference_set.3 ./usr/opt/bstman300/man/man3/bstr_reference_unset.3 ./usr/opt/bstman300/man/man3/bstr_references_are_equal.3 ./usr/opt/bstman300/man/man3/bstr_sequence_append_elements.3 ./usr/opt/bstman300/man/man3/bstr_sequence_copy.3 ./usr/opt/bstman300/man/man3/bstr_sequence_create.3 ./usr/opt/bstman300/man/man3/bstr_sequence_discard.3 ./usr/opt/bstman300/man/man3/bstr_sequence_get_element_by_key.3 ./usr/opt/bstman300/man/man3/bstr_sequence_get_elements.3 ./usr/opt/bstman300/man/man3/bstr_sequence_get_info.3 ./usr/opt/bstman300/man/man3/bstr_sequence_insert_elements.3 ./usr/opt/bstman300/man/man3/bstr_sequences_are_equal.3 ./usr/opt/bstman300/man/man3/bstr_time_compare.3 ./usr/opt/bstman300/man/man3/bstr_time_convert.3 ./usr/opt/bstman300/man/man3/bstr_time_to_string.3 ./usr/opt/bstman300/man/man3/bstr_trc_finish.3 ./usr/opt/bstman300/man/man3/bstr_trc_initialize.3 ./usr/opt/bstman300/man/man3/bstr_trc_trace.3 ./usr/opt/bstman300/man/man3/bstr_trigger_disable.3 ./usr/opt/bstman300/man/man3/bstr_trigger_enable.3 ./usr/opt/bstman300/man/man3/bstr_vmd_load_definitions.3 ./usr/opt/bstman300/man/man3/bstr_vmd_loop.3 A-11 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems A.1.3 Files Installed by the DOUBASE300 Subset /usr/opt/DOU300 /usr/opt/DOU300/bin /usr/opt/DOU300/bin/omni_server /usr/opt/DOU300/docs /usr/opt/DOU300/docs/DEComni300.release_notes /usr/opt/DOU300/etc /usr/opt/DOU300/etc/omni_config.csh /usr/opt/DOU300/etc/omni_ivp.sh /usr/opt/DOU300/etc/omni_schema.sh /usr/opt/DOU300/etc/omni_startup.sh /usr/opt/DOU300/etc/omniview_help.txt /usr/opt/DOU300/examples /usr/opt/DOU300/examples/makefile /usr/opt/DOU300/examples/omni_ivp_init.c /usr/opt/DOU300/examples/omni_ivp_resp.c /usr/opt/DOU300/examples/omni_run_time_pi_dom.c /usr/opt/DOU300/examples/omni_run_time_var.c /usr/opt/DOU300/examples/omni_run_time_vmd.c /usr/opt/DOU300/include /usr/opt/DOU300/include/omni_api_protos.h /usr/opt/DOU300/include/omni_codes.h /usr/opt/DOU300/include/omni_defs.h /usr/opt/DOU300/include/omni_integrator2_defs_include.h /usr/opt/DOU300/include/omni_integrator3_defs_include.h /usr/opt/DOU300/include/omni_integrator4_defs_include.h /usr/opt/DOU300/include/omni_integrator5_defs_include.h /usr/opt/DOU300/include/omni_integrator6_defs_include.h /usr/opt/DOU300/include/omni_integrator7_defs_include.h /usr/opt/DOU300/include/omni_integrator8_defs_include.h /usr/opt/DOU300/include/omni_integrator9_defs_include.h /usr/opt/DOU300/include/omni_integrator10_defs_include.h /usr/opt/DOU300/include/omni_integrator11_defs_include.h /usr/opt/DOU300/include/omni_integrator12_defs_include.h /usr/opt/DOU300/include/omni_integrator13_defs_include.h /usr/opt/DOU300/include/omni_integrator14_defs_include.h /usr/opt/DOU300/include/omni_integrator15_defs_include.h /usr/opt/DOU300/include/omni_integrator16_defs_include.h /usr/opt/DOU300/lib /usr/opt/DOU300/lib/basic /usr/opt/DOU300/lib/basic/libomni.a /usr/opt/DOU300/lib/client A-12 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems /usr/opt/DOU300/lib/client/libomni.a /usr/opt/DOU300/lib/decomni.cat /usr/opt/DOU300/lib/osak /usr/opt/DOU300/lib/server /usr/opt/DOU300/lib/server/libomni.a /usr/opt/DOU300/local /usr/opt/DOU300/msg /usr/opt/DOU300/ods /usr/opt/DOU300/ods/examples /usr/opt/DOU300/ods/examples/ods_example.c /usr/opt/DOU300/ods/exe /usr/opt/DOU300/ods/exe/ods_cache_utility /usr/opt/DOU300/ods/exe/ods_rehash_directory /usr/opt/DOU300/ods/exe/ods_schema_utility /usr/opt/DOU300/ods/exe/ods_tester /usr/opt/DOU300/ods/exe/odscl /usr/opt/DOU300/ods/help /usr/opt/DOU300/ods/help/odscl_add_expression.txt /usr/opt/DOU300/ods/help/odscl_attr_abbrev.txt /usr/opt/DOU300/ods/help/odscl_attr_expression.txt /usr/opt/DOU300/ods/help/odscl_attr_prompt.txt /usr/opt/DOU300/ods/help/odscl_command_elements.txt /usr/opt/DOU300/ods/help/odscl_command_syntax.txt /usr/opt/DOU300/ods/help/odscl_commands.txt /usr/opt/DOU300/ods/help/odscl_continuation.txt /usr/opt/DOU300/ods/help/odscl_deregister.txt /usr/opt/DOU300/ods/help/odscl_deregister_examples.txt /usr/opt/DOU300/ods/help/odscl_deregister_syntax.txt /usr/opt/DOU300/ods/help/odscl_directory_prompt.txt /usr/opt/DOU300/ods/help/odscl_displays.txt /usr/opt/DOU300/ods/help/odscl_exit.txt /usr/opt/DOU300/ods/help/odscl_file_prompt.txt /usr/opt/DOU300/ods/help/odscl_help.idx /usr/opt/DOU300/ods/help/odscl_help.txt /usr/opt/DOU300/ods/help/odscl_invoking.txt /usr/opt/DOU300/ods/help/odscl_list.txt /usr/opt/DOU300/ods/help/odscl_list_examples.txt /usr/opt/DOU300/ods/help/odscl_list_syntax.txt /usr/opt/DOU300/ods/help/odscl_local_directory.txt /usr/opt/DOU300/ods/help/odscl_match_expression.txt /usr/opt/DOU300/ods/help/odscl_match_prompt.txt /usr/opt/DOU300/ods/help/odscl_modify.txt /usr/opt/DOU300/ods/help/odscl_modify_examples.txt A-13 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems /usr/opt/DOU300/ods/help/odscl_modify_prompt.txt /usr/opt/DOU300/ods/help/odscl_modify_syntax.txt /usr/opt/DOU300/ods/help/odscl_name_expression.txt /usr/opt/DOU300/ods/help/odscl_name_prompt.txt /usr/opt/DOU300/ods/help/odscl_oc_abbrev.txt /usr/opt/DOU300/ods/help/odscl_option_abbrev.txt /usr/opt/DOU300/ods/help/odscl_path_expression.txt /usr/opt/DOU300/ods/help/odscl_path_prompt.txt /usr/opt/DOU300/ods/help/odscl_prompts.txt /usr/opt/DOU300/ods/help/odscl_read.txt /usr/opt/DOU300/ods/help/odscl_read_examples.txt /usr/opt/DOU300/ods/help/odscl_read_syntax.txt /usr/opt/DOU300/ods/help/odscl_register.txt /usr/opt/DOU300/ods/help/odscl_register_examples.txt /usr/opt/DOU300/ods/help/odscl_register_syntax.txt /usr/opt/DOU300/ods/help/odscl_remove_expression.txt /usr/opt/DOU300/ods/help/odscl_replace_expression.txt /usr/opt/DOU300/ods/help/odscl_set.txt /usr/opt/DOU300/ods/help/odscl_set_examples.txt /usr/opt/DOU300/ods/help/odscl_set_syntax.txt /usr/opt/DOU300/ods/help/odscl_show.txt /usr/opt/DOU300/ods/help/odscl_show_examples.txt /usr/opt/DOU300/ods/help/odscl_show_syntax.txt /usr/opt/DOU300/ods/help/odscl_to_file_expression.txt /usr/opt/DOU300/ods/help/odscl_to_prompt.txt /usr/opt/DOU300/ods/help/odscl_with_expression.txt /usr/opt/DOU300/ods/help/odscl_with_prompt.txt /usr/opt/DOU300/ods/help/odsview_help.txt /usr/opt/DOU300/ods/include /usr/opt/DOU300/ods/include/ods_defs.h /usr/opt/DOU300/ods/include/ods_msg.h /usr/opt/DOU300/ods/lib /usr/opt/DOU300/ods/lib/libods.a /usr/opt/DOU300/ods/scripts /usr/opt/DOU300/ods/scripts/ods_ivp.sh /usr/opt/DOU300/ods/scripts/ods_startup.sh /usr/var/opt/DOU300 /usr/var/opt/DOU300/ods /usr/var/opt/DOU300/ods/cache /usr/var/opt/DOU300/ods/local /usr/var/opt/DOU300/ods/local/ods_known_attribute_types.dat /usr/var/opt/DOU300/ods/local/ods_known_object_classes.dat /usr/var/opt/DOU300/ods/local/ods_version.dat A-14 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems /usr/var/opt/DOU300/ods/local/odscl_parse_tbl.bin A.1.4 Files Installed by the DOUMAN300 Subset /usr/share/man/man3/omni_abort.3 /usr/share/man/man3/omni_accept_conclude.3 /usr/share/man/man3/omni_accept_connect.3 /usr/share/man/man3/omni_cancel.3 /usr/share/man/man3/omni_conclude.3 /usr/share/man/man3/omni_connect.3 /usr/share/man/man3/omni_create.3 /usr/share/man/man3/omni_define.3 /usr/share/man/man3/omni_delete.3 /usr/share/man/man3/omni_download.3 /usr/share/man/man3/omni_end_list.3 /usr/share/man/man3/omni_fdelete.3 /usr/share/man/man3/omni_fdir.3 /usr/share/man/man3/omni_fget.3 /usr/share/man/man3/omni_fput.3 /usr/share/man/man3/omni_frename.3 /usr/share/man/man3/omni_get_attribute.3 /usr/share/man/man3/omni_get_definition.3 /usr/share/man/man3/omni_get_fd.3 /usr/share/man/man3/omni_get_handle_by_name.3 /usr/share/man/man3/omni_get_handle_list.3 /usr/share/man/man3/omni_get_indications.3 /usr/share/man/man3/omni_get_message_text.3 /usr/share/man/man3/omni_get_remote_attributes.3 /usr/share/man/man3/omni_get_value.3 /usr/share/man/man3/omni_group_variables.3 /usr/share/man/man3/omni_initialize.3 /usr/share/man/man3/omni_kill.3 /usr/share/man/man3/omni_listen.3 /usr/share/man/man3/omni_modify_definition.3 /usr/share/man/man3/omni_poll.3 /usr/share/man/man3/omni_print_message.3 /usr/share/man/man3/omni_put_value.3 /usr/share/man/man3/omni_reject.3 /usr/share/man/man3/omni_reject_conclude.3 /usr/share/man/man3/omni_reject_connect.3 /usr/share/man/man3/omni_reset.3 /usr/share/man/man3/omni_resume.3 /usr/share/man/man3/omni_send_value.3 /usr/share/man/man3/omni_set_application_profile.3 A-15 Files Installed by BASEstar Open Server A.1 Digital UNIX Systems /usr/share/man/man3/omni_start.3 /usr/share/man/man3/omni_stop.3 /usr/share/man/man3/omni_terminate.3 /usr/share/man/man3/omni_upload.3 A-16 B _________________________________________________________________ BASEstar Open Global Variables This appendix describes the BASEstar Open global variables. BASEstar Open global variables provide application and environment components with a generalized mechanism for the exchange of information. BASEstar Open global variables are shell environment variables that you can set using either standard UNIX features. For details, refer to the platform-dependent documentation for the shell in question. B.1 Global Variable List Table B-1 lists all the BASEstar Open global variables. For ease of reference, the global variables are grouped according to the time they are set and the time they are used. Table_B-1_BASEstar_Open_Global_Variables_________________________ Variable_Name______________Description___________________________ _____________Installation-specific_global_variables______________ BSTR_BIN The absolute pathname of the bin directory where the BASEstar Open executables are stored. BSTR_ETC The absolute pathname of the etc directory where the BASEstar Open environment commands and command file are stored. (continued on next page) B-1 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ Variable_Name______________Description___________________________ ______________Installation-specific_global_variables_____________ BSTR_INCLUDE The absolute pathname of the include directory where BASEstar Open stores the API include files. BSTR_LIB The absolute pathname of the lib directory where BASEstar Open stores the API library. BSTR_WORK_ROOT The absolute pathname of the root directory of the subtree where BASEstar Open stores temporary files at run-time. The default value is /var/opt /bstbase300/spool_root/work. BSTR_DBACCESS_KEY The root directory where BASEstar Open stores snapshot configuration files created on the PODB Node. The default value is /usr/var/opt /bstbase300/spool_root/snapshot. (continued on next page) B-2 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ _________________________________________________________________ Global variables for activating Event ___________Services_and_Data_&_Device_Services_servers___________ BSTR_ACTIVITY Name of the Activity to be started within the server (string of up to 32 characters, in accordance with BASEstar Open local name syntax). If you specify more than one name, use blanks to separate each name. BSTR_DATABASE The type of database. Set this qualifier to SNAPSHOT. (continued on next page) B-3 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ Variable_Name______________Description___________________________ Global variables for activating Event ___________Services_and_Data_&_Device_Services_servers___________ BSTR_DBVERSION The major identifier of the snapshot configuration to be loaded. If the BSTR_DBVERSION global variable is not set, the most recent one (having the highest major identifier) is assumed by default. BSTR_DDM_SERVER BSTR_DEVICE_GEN_TH_SIZE The DEVICE general thread stack size. BSTR_DEVICE_I_SIZE The DEVICE management initial memory pool. (continued on next page) B-4 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ Variable_Name______________Description___________________________ Global variables for activating Event ___________Services_and_Data_&_Device_Services_servers___________ BSTR_DOMAIN The name of the resources handled by an Activity. This global variable must only be set for Event Services, Packet Services and Data & Device Services servers, as follows: o PACKET. The global variable must contain the full name of a Domain object. When BASEstar Open executes the Packet Services server, the associated Activity execution makes the Packet Services objects created within the specified Domain available to the clients. o EVENT. The global variable must contain the full name of a Domain object. When BASEstar Open executes the Event Services server, the associated Activity execution makes the Event Services objects created within the specified Domain available to the clients. o DATA. The global variable must contain the full name of a Domain object. When BASEstar Open executes the Data & Device Services server, the associated Activity execution makes the Data & Device Services objects created within the specified Domain available to the clients. (continued on next page) B-5 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ Variable_Name______________Description___________________________ Global variables for activating Event ___________Services_and_Data_&_Device_Services_servers___________ BSTR_EVM_SERVER (continued on next page) B-6 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ Variable_Name______________Description___________________________ Global variables for activating Event ___________Services_and_Data_&_Device_Services_servers___________ BSTR_LOCAL_VMD_NAME The name of the VMD definition to be used as the calling VMD when accessing a remote VMD. If specified for a Device Services server, this VMD represents the calling VMD used by the actual Device Services server to reach the device VMD. When specified for a Data Services server or a CLI command interpreter instance, this VMD represents the calling VMD used by the actual Data Services server (or CLI instance) to reach the device VMD or Device Services server VMD. BSTR_POLLING_FACTOR The time scale factor for Polling_ Sets. BSTR_RETRY_CONN_TIME The value assigned to the BSTR_RETRY_ CONN_TIME variable specifies the number of seconds that the server waits before attempting to restart the association with the physical device after a connection failure. The default value is 30 seconds. (continued on next page) B-7 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ Variable_Name______________Description___________________________ Global variables for activating Event ___________Services_and_Data_&_Device_Services_servers___________ BSTR_STAT_ENABLED If this global variable is set, the server enables statistics collection for each object made available (provided that the object supports statistics collection). If this global variable is not defined when a BASEstar Open-supplied server is started up, BASEstar Open disables statistics collection for that server. BSTR_VMD This qualifier is only significant for a Device Services server and must contain the name of one or more Device Services VMDs. If you specify more than one name, use blank spaces to separate them. _________________________________________________________________ ______________________Realm_global_variable______________________ BSTR_REALM The local name of the Realm that BASEstar Open sets as the current Realm. _________________________________________________________________ Global_variables_for_activating_the_Global_Object_Services_server BSTR_GOM_MAX_CLIENT The maximum number of client application components supported by the Global Object Services server (continued on next page) B-8 BASEstar Open Global Variables B.1 Global Variable List Table_B-1_(Cont.)_BASEstar_Open_Global_Variables_________________ _________________________________________________________________ ________Application_Management_Services_global_variables_________ BSTR_DIRECTORY The pathname specified in the directory attribute of the Node on which the Program execution is running. BSTR_PROGRAM The full name of the associated Program. _________________________________________________________________ _______Global_variables_for_activating_the_Trace_Database________ BSTR_TRC_PATH The pathname of the directory in which the Trace Database resides. The default location on UNIX platforms is as follows: o $BSTR_WORK_ROOT/node/trc (for BASEstar Open Node processes) o $BSTR_WORK_ROOT/realm/$BSTR_REALM /trc (for BASEstar Open Realm processes) _________________________________________________________________ __________________________Miscellaneous__________________________ BSTR_CONN_MODE The local VMD connection behavior BSTR_DADE_STACT_TH_SIZE____Activity_control_thread_stack_size____ B.2 Installation-specific Global Variables The bstr_node_setup command creates the appropriate command files that contain the commands used to set the installation-specific global variables. The values of the global variables depend on the values you specified when installing BASEstar Open and executing the bstr_node_setup command. To set the values of the global variables for a user, you must execute the appropriate command file which is stored in the /etc directory. B-9 BASEstar Open Global Variables B.2 Installation-specific Global Variables B.2.1 Setting the Values of Global Variables The following scripts are available: o bstrusers.sh is a Bourne shell script If you are working with a Bourne shell, you can insert the following line in your .login file: source /etc/bstrusers.sh o bstrusers.csh is a cshell script If you are working with cshell, you can insert the following line in your .login file: source /etc/bstrusers.csh B.3 BSTR_REALM Global Variable The BSTR_REALM global variable contains the name of the Realm to be operated on. Assign a valid Realm name to this global variable as required (before activating the BASEstar Open CLI or a BASEstar Open application from the command interpreter). For example, you can enter the following command line at the Bourne shell prompt: $ BSTR_REALM=MY_REALM; export BSTR_REALM You can enter the following command line at the cshell prompt: $ setenv BSTR_REALM MY_REALM B.4 Global Variables for Server Activation Before activating an Event Services or Data & Device Services server from the command interpreter, you must set the global variables to the appropriate values, as described in Chapter 8. Note that if you activate a server via Application Management Services, BASEstar Open sets the values for these variables automatically. B-10 BASEstar Open Global Variables B.5 Application Management Services Global Variables B.5 Application Management Services Global Variables The bstr_initialize function returns the BSTR_PROGRAM and BSTR_DIRECTORY global variables when BASEstar Open activates a user-written application via the Application Management Services. Appendix C explains how to set one or more user-defined global variables that Application Management Services make available to the activated Program execution. B-11 C _________________________________________________________________ Environment and Parameter Files This appendix describes the format and contents of the following files: o The environment file whose pathname is specified in the environment attribute of a Node object. o The parameters file whose pathname is specified in the parameters attribute of a Program object. These files are optional; if you do not create them, Application Management Services set up the environment using default values. You can also use an ASCII editor to create the files. C.1 General Record Format Each record in the environment or parameter file must be terminated by pressing the key. If one or more blank characters are left at the beginning of a line, the entire line (up to ) is assumed to be a comment. The record format follows the syntax shown below: object.item:value where: o object represents: - The full name of a Program in a Program parameter file. This means that you can specify parameters relating to different Programs in the same file. - The local name of a Node object in a Node environment file. This means that you can specify parameters relating to different Nodes in the same file. o item represents a valid item identifier (according to the type of file). C-1 Environment and Parameter Files C.1 General Record Format o value represents the value of item. C-2 Environment and Parameter Files C.2 Format of the File for the Node environment Attribute C.2 Format of the File for the Node environment Attribute This section describes the format and the contents of the file whose pathname can be specified in the environment attribute of a Node object. This file contains the value for one or more global variables. The Application Management Services server sets the values for these global variables at Node startup time for all the processes activated on the Node that run the image associated with any Program. You can use these global variables to: o Express the pathnames set as values of the Program parameters and image attributes o Set the values for the input, output and error items of a Program parameter file Table C-1 describes the valid keywords for item. Table C-1 Valid Values of the File for the Node environment __________Attribute________________________________________ Item IdentifierType______Description____________________________ env string Each env argument identifies a BASEstar Open global variable, and the value to be assigned to it. You can define zero, one, or as many items as there are global variables to be set. The value field must be in the form "NAME=VALUE", where NAME is the name of the global variable, and VALUE is the value to be assigned to it. BASEstar Open global variables are set in the order in which they are ____________________encountered_in_the_file._______________ ________________________ Note ________________________ A value specified for an environment variable in the Node environment file overrides a value set for the same variable by the bstr_realm_start_node command. ______________________________________________________ C-3 Environment and Parameter Files C.2 Format of the File for the Node environment Attribute Below is an example of a Node environment file. The information contained in this file causes the Application Management Services to set the DISPLAY and WHEREIS environment variables before it activates any of the Program executions on NODE1 or NODE2. NODE1.env:DISPLAY=martes:0.0 NODE1.env:WHEREIS=10 NODE2.env:DISPLAY=drago:0.0 NODE2.env:WHEREIS=16 C.3 Format of the File for the Program parameters Attribute As specified in the Program parameters attribute, this file contains information used by the Application Management Services during activation of the process in which the Program image is run. If you do not specify this file, or if it does not contain settings for all the parameters to be used, BASEstar Open assumes the default values. ________________________ Note ________________________ The value specified for a global variable in the Program parameter file overrides the value specified for the same variable by the bstr_realm_start_node command. The value specified for a global variable in the Program environment file also overrides the value specified for the same variable in the Node environment file. ______________________________________________________ C.3.1 File Format Table C-2 describes the valid values for item. C-4 Environment and Parameter Files C.3 Format of the File for the Program parameters Attribute Table C-2 Valid Values of the File for the Program __________parameters_Attribute_____________________________ Item IdentifierType______Description____________________________ input pathname Standard input file[1]. (Default value is /dev/null.) output pathname Standard output file[1]. (Default value is /dev/null.) error pathname Standard error file[1]. (Default value is /dev/null.) arg0 string Identifies the value to be assigned to the arg[0] element of the program argument vector (arg[]). If this record is not specified, the arg[0] element is assigned the name of the program executable image (see the examples given at the end of this section). [1]The_pathnames_specified_in_the_input,_output_and________ error items can also be expressed using one or more of the environment variables previously set in the Node environment file. The name of each environment variable must be enclosed within parentheses and must be preceded by the dollar sign ($). For example, if the USER environment variable has been set to foo, and the BIN environment variable has been set to mips/bin, the pathname /usr/foo /mips/bin/my_program can be expressed as /usr/$(USER) /$(BIN)/my_program. (continued on next page) C-5 Environment and Parameter Files C.3 Format of the File for the Program parameters Attribute Table C-2 (Cont.) Valid Values of the File for the Program __________________parameters_Attribute_____________________ Item IdentifierType______Description____________________________ arg string Each arg argument identifies the value to be assigned to an element of the program argument vector (arg[]). You can define zero, one, or as many arguments as there are process activation arguments. These arguments are passed to the program being run in the order in which they are encountered in the file. The first specified argument corresponds to arg[1], the second to arg[2], and so on. env string Each env argument identifies a shell environment variable and the value to be assigned to it. You can define zero, one, or as many items as there are environment variables to be set. The value field must be in the form "NAME=VALUE", where NAME is the name of the environment variable, and VALUE is the value to be assigned to it. Environment variables are set in the order in which they are encountered in the file. prio integer The priority to be assigned to the process in which the Program image ____________________runs.__________________________________ An example of a parameter file is given below. The information contained in this file causes the Application Management Services to set the DISPLAY and MY_PATH environment variables before it activates the application process. In order for it to be activated, the process must be assigned a priority value of 0. Furthermore, the three activation arguments must be passed to it, in the order shown below. C-6 Environment and Parameter Files C.3 Format of the File for the Program parameters Attribute /PROGRAM_1.input: /dev/ttyp1 /PROGRAM_1.output: /dev/ttyp1 /PROGRAM_1.error: /dev/ttyp1 /PROGRAM_1.env: DISPLAY=martes:0.0 /PROGRAM_1.env: MY_PATH=/usr/users/bianchi /PROGRAM_1.arg: argument_1 /PROGRAM_1.arg: argument_2 /PROGRAM_1.arg: argument_3 /PROGRAM_1.prio: 0 C-7 D _________________________________________________________________ Environment Component Processes This appendix provides information about the platform- dependent processes that implement each BASEstar Open environment component. The main purpose of this appendix is to enable a system administrator to monitor (using standard tools) the processes that implement environment components (activated by environment commands in transparent mode). Note that BASEstar Open: o Activates the processes that implement Node-specific components when you execute the bstr_node_start command. o Activates the processes that implement Realm-specific components when you execute the bstr_realm_start_node command See Chapter 4 and Chapter 6 for a description of the environment components and the environment commands, respectively. D-1 Environment Component Processes D.1 Processes D.1 Processes Table D-1 lists all the processes that implement the Node- and Realm-specific environment components on a UNIX Node. D-2 Environment Component Processes D.1 Processes Table_D-1_Processes______________________________________________ Process Description______Executable_Image_________Notes__________________ ______________Node-Specific_Environment_Components_______________ Log Services LOG_SERVER server Watchdog /usr/kits/bstr300/bin /watchd Watchdog /usr/kits/bstr300/bin Listener /watchld Name Service /usr/kits/bstr300/bin Client /lnshm Name Service /usr/kits/bstr300/bin Server /lnssr LNS Monitor /usr/kits/bstr300/bin /com_lns_mon _________________________________________________________________ ______________Realm-Specific_Environment_Components______________ Communication /usr/opt/bstbase300/bin Where is the Service /ce -r name of the associated Enabler Realm. Communication /usr/opt/bstbase300/bin Where is the Service /cns -r name of the associated Name Server Realm. Communication /usr/opt/bstbase300/bin Where is the Service /rcmtcp -r name of the associated. Remote Communication Manager for TCP/IP Global Object /usr/opt/bstbase300/bin Where realm is the Services server /gom_server -r name of the associated Realm. Application /usr/opt/bstbase300/bin Where realm is the Management /ams_server -r name of the associated Services server Realm. Database /usr/opt/bstbase300 Where realm is the Service server /bin/cnf_dbserver -r name of the associated Realm. Only on PODB Nodes, if the bstr_realm_startup_ db command has been executed. PC /usr/opt/bstbase300/bin Where realm is the Communication /lcpisrv -r name of the associated server____________________________________Realm._________________ E _________________________________________________________________ Managing Snapshot Files in a Distributed Environment This appendix is relevant to Digital UNIX systems only. You can only create snapshots on the PODB Node of a Realm. However, if you wish to perform operations on a Realm of a multi-node and distributed BASEstar Open environment, you must identify the snapshot files for each server Node on which the Realm is to be started up, and make them accessible to the BASEstar Open-supplied servers. The information in this appendix is only addressed to users who are running BASEstar Open in a multi-node distributed environment. Note that there is no need to make snapshot files accessible from a client Node. This appendix describes: o The location of snapshot files and directories in a PODB Node o Platform-dependent tools for accessing snapshot files from Nodes other than the PODB Node. E.1 Using Configuration Management Commands in a Multi-node Environment You can use the following CLI commands to create and manage snapshot files: o GENERATE SNAPSHOT o DUMP SNAPSHOT o GET INFO SNAPSHOT o PURGE SNAPSHOT o RESET SNAPSHOT o UPGRADE SNAPSHOT E-1 Managing Snapshot Files in a Distributed Environment E.1 Using Configuration Management Commands in a Multi-node Environment For further information, refer to the BASEstar Open Command Language Interface. It is important to specify that for a given Realm: o Snapshot management CLI commands can be executed by any user active on any Node o Execution of snapshot management CLI commands create snapshot files only under the snapshot directory on the PODB Node. E.2 Snapshot File Location On a PODB Node, snapshot files are stored in the following directory: $BSTR_DBACCESS_KEY/realm_name/version_version where: o BSTR_DBACCESS_KEY is the global variable that specifies the root directory where BASEstar Open stores snapshot configuration files created on the PODB Node. o The realm_name subdirectory is the directory where snapshot files are created for the corresponding Realm. o There is a version_version subdirectory for each snapshot configuration version that has been created, where version is a three-digit version number padded with zeroes. For example, directory $BSTR_DBACCESS_KEY/my_realm/version_ 002 contains the snapshot files for version 2 of the my_ realm Realm. Note also that: o The $BSTR_DBACCESS_KEY/realm_name directory is created on a Node when the bstr_realm_setup_node has been executed on that Node for the realm_name Realm. o A version subdirectory is created each time the GENERATE SNAPSHOT command is executed for the Realm. E-2 Managing Snapshot Files in a Distributed Environment E.3 The BSTR_DBACCESS_KEY Global Variable E.3 The BSTR_DBACCESS_KEY Global Variable The examples described in this appendix assume that the $BSTR_DBACCESS_KEY global variable has been set to its default value. See Appendix B for details. E.4 Making Snapshot Files Accessible You can make snapshot files accessible in two ways: o By mounting snapshot directories with NFS o By copying the snapshot files to each server Node that requires them. The universal format of snapshot files also allows you to port them from one platform to another. For example, a snapshot generated in a Windows NT environment can also be loaded on a OpenVMS or Digital UNIX system. E.4.1 Mounting Snapshot Directories with NFS Only one copy of the snapshot files must exist, and it is the original copy created through the snapshot CLI commands under the snapshot directories of the PODB Node, as explained in Section E.2. Note that one mount operation gives access to all snapshots that have been created on the PODB Node. Issuing the Mount Command On all the Nodes from which the snapshot files must be made accessible, you must issue the following command (as a superuser): # mount -r podb_node_name:$BSTR_DBACCESS_KEY $BSTR_DBACCESS_KEY This command works successfully if the $BSTR_DBACCESS_KEY directory has been defined to be exportable by the system manager of the PODB Node. See also mount(1) and exports(4). When to Mount the Snapshot Directory You must issue the mount command before accessing snapshots. You must issue the mount command only once; for example, you can insert the mount command in the /etc /fstab file to mount the snapshot directory automatically at system boot. E-3 Managing Snapshot Files in a Distributed Environment E.4 Making Snapshot Files Accessible E.4.2 Copying Snapshot Files Using a File Transfer A copy of the snapshot files for a given Realm must exist on each involved Node. This means that you must create on any Node that requires it an appropriate subtree of the $BSTR_DBACCESS_KEY directory. You must also copy all the files that exist under the $BSTR_DBACCESS_KEY/realm_ name and $BSTR_DBACCESS_KEY/realm_name/version_version directories on the PODB Node, to the directories having the same name on the current Node. You can use any command or utility you find appropriate. Only the user who issued the bstr_realm_setup_node command (that is, the Realm user) can copy the snapshot files on the destination Node. The operations described below must be repeated for each Realm that must be operated in the multi-node environment. Creating the Snapshot Subtree on a Node You must perform the following operations: o Execute bstr_realm_setup_node for realm_name. This command also creates the $BSTR_DBACCESS_KEY snapshot root directory and the $BSTR_DBACCESS_KEY/realm_name directory. You must perform this operation only once on a Node for the realm_name Realm. o Create as many version_version directories under the $BSTR_DBACCESS_KEY/realm_name directory as many snapshot versions you want to use for the realm_name Realm. What to Copy and How You must copy the appropriate snapshot files on all the Nodes from where the snapshot files for the realm_name Realm and version version have to be made accessible. For example, to copy with ftp all snapshot files for Realm my_realm and version 3, you can manage as follows (where NODEA is the hostname of the system hosting the PODB Node and /usr/spool/bstr/snapshot is the default snapshot directory): E-4 Managing Snapshot Files in a Distributed Environment E.4 Making Snapshot Files Accessible $ ftp NODEA .... .... "enter user name and password" .... ftp> binary ftp> lcd /usr/spool/bstr/snapshot/my_realm ftp> mget /usr/spool/bstr/snapshot/my_realm/* ftp> lcd /usr/spool/bstr/snapshot/my_realm/version_003 ftp> mget /usr/spool/bstr/snapshot/my_realm/version_003/* ftp>bye $ You must repeat the above operations for each version of the snapshot files you want to make accessible. When to Copy the Snapshot Files You must copy the snapshot files each time you perform an UPGRADE SNAPSHOT or a GENERATE SNAPSHOT operation. In this latter case, you must first create the directory as explained in Creating the Snapshot Subtree on a Node. E-5 _________________________________________________________________ Index A BASEstar Open-supplied servers _______________________________ (cont'd) Application Management Event Services, 8-9 Services Monitor, 9-1 Global Object Services, 8-5 Activity view, 9-9 Packet Services, 8-12 Actor view, 9-6 PC Communication server, Node view, 9-15 8-26 Process view, 9-13 startup, 8-1 Program view, 9-11 bstr_env_show, 5-14, 6-5 running the, 9-2 bstr_node_setup, B-9 bstr_node_shut, 6-20 B______________________________ bstr_node_start, 4-3, 6-22 BASEstar CIMfast bstr_node_unset, 6-24 installing, 3-1 to 3-4 bstr_realm_check_env, 5-14, installing from CD-ROM, 3-1 6-26 BASEstar Open bstr_realm_setup_db, 6-29 setup, 4-1 bstr_realm_setup_node, 6-31 shutdown, 4-1 bstr_realm_shut_db, 6-33 startup, 4-1 bstr_realm_shut_node, 6-34 BASEstar Open Environment bstr_realm_start, 4-5 monitoring, 5-14 bstr_realm_start_db, 4-4, 6-36 BASEstar Open Environment bstr_realm_start_node, 6-37, Monitor, 7-1 8-5, 8-7, 8-26 active Node view, 7-7 bstr_realm_unset_db, 6-39 active Realm view, 7-4 bstr_realm_unset_node, 6-41 running the, 7-3 bstr_run, 6-43 BASEstar Open-supplied servers Application Management C______________________________ Services, 8-7 CLI Commands Data & Device Services server DISPLAY , 8-23 LOG, 10-1, 10-9, 11-2 Data Services server, 8-15 OPEN Device Services, 8-19 LOG, 10-1, 11-4 Index-1 Communication Service, 4-6 Installation (Digital UNIX) Configuration (cont'd) loading Application release notes, 1-1 Management Services software requirements, 1-5 objects, 8-7 terminating the, 1-8 loading global objects, 8-5 Installation Verification Creating Procedure (IVP) log files save copies, 10-1 for Digital UNIX, 2-4, 2-5 to 2-8 D______________________________ Displaying L______________________________ environment information, LOAD CONFIGURATION, 8-5, 8-7 10-1 Log files log files component identifier, 10-3 save copies, 10-8 creating save copies, 10-1 working copies, 10-8 displaying save copies, 10-8 displaying working copies, E______________________________ 10-8 Environment location directory, 10-2 Log Services, 10-1 purging save copies, 10-2 Environment components record format, 10-3 corresponding processes, D-1 saving copies, 10-1 processes, D-2 server information, 8-4 Environment file working copies, 10-1 record format, C-1 Logging Executing environment commands environment information, UNIX 10-1 from the right user, 6-1 Log Services, 4-3 general operations, 6-3 CLI commands, 10-1 server, 10-1 G______________________________ server activities, 10-9 Global variables, B-1, E-1 shutting down the server, inheritance and usage, 8-7 10-9 setting the values of, B-9, starting up the server, 10-9 B-10 M _______________________________ I______________________________ Monitoring Installation (Digital UNIX) BASEstar Open, 4-2, 5-14 checking kit contents, 1-3 disk space requirements, 1-6 to 1-8 hardware requirements, 1-4 procedure, 2-1 to 2-5 Index-2 N______________________________ S______________________________ Name Service, 4-3 Setting up Node BASEstar Open, 4-1 setup, 5-2 Nodes, 5-2 shutdown, 5-8 Realms, 5-2 startup, 5-5 Shutting down unset, 5-12 BASEstar Open, 4-1 Nodes Nodes, 5-8 components Realms, 5-8 Log Services, 4-3 Shutting down a Data Services Name Service, 4-3 server Watchdog, 4-3 from the command interpreter, 8-17 P______________________________ using Application Management Parameter file Services, 8-16 record format, C-1 Shutting down a Device Passive device connections Services server using Data & Device Services, from the command interpreter, 8-25 8-21 PODB Node, 4-4 using Application Management Pre-installation tasks Services, 8-21 Digital UNIX, 1-1 Shutting down an Event Purging Services server log files save copies, 10-2 from the command interpreter, 8-9 R______________________________ using Application Management Realm Services, 8-9 components, 4-5 Shutting down an Packet Application Management Services server Services server, 4-6 from the command interpreter, Communication Service, 8-12 4-6 using Application Management Database Services server, Services, 8-12 4-4, 4-7 Snapshots Global Object Services directory location, E-2 server, 4-6 using from servers, 8-3 PC Communication server, Starting up 4-7 BASEstar Open, 4-1 setup, 5-2 BASEstar Open-supplied shutdown, 5-8 servers, 8-1 startup, 5-5 Nodes, 5-5 unset, 5-12 Realms, 5-5 Index-3 Starting up a Data Services Starting up an Packet Services server server from the command interpreter, from the command interpreter, 8-17 8-12 using Application Management using Application Management Services, 8-16 Services, 8-12 Starting up a Device Services server U______________________________ from the command interpreter, Unsetting 8-21 BASEstar Open, 4-2 using Application Management Nodes, 5-12 Services, 8-21 Realms, 5-12 Starting up an Event Services server V______________________________ from the command interpreter, VMD 8-9 specifying the calling, 8-19 using Application Management Services, 8-9 W _______________________________ Watchdog, 4-3 Index-4