DECserver 200 ______________________________________________________________________ Software Installation Guide (VMS) June 1989 This guide tells you how to install the DECserver 200 distribution software onto a VMS system, how to configure the system as a down-line load host, and how to verify the installation. This guide is intended for the VMS system manager or the network manager. Supersession/Update Information: This is a revised manual. Operation System and Version: VMS 4.7 and 5.0 Software Version DECserver 200 V3.0 This manual applies to Version 3.0 of DECserver 200 and all subsequent maintenance releases up to the next major product release. DIGITAL Order No. AA-HL79C-TK _____________________________________________________ Contents 1. Introducing the DECserver 200 Terminal Server 1.1 What Is the DECserver 200 Terminal Server? 1.2 DECserver 200 Concepts 1.2.1 Connections 1.2.2 Services 1.2.3 Service Nodes and LAT Protocol 1.2.4 LAT Software 1.3 Performing the Software Installation 1.3.1 Installing the DECserver 200 Distribution Software 1.3.2 Configuring the Load Host's Node Database 1.3.3 Verifying the Installation 1.3.3.1 Verifying the Load Host Installation 1.3.3.2 Verifying the Server System Installation 2. Installing the DECserver 200 Distribution Software 2.1 Overview of VMSINSTAL 2.2 Preparing to Run the Installation Procedure 2.3 VMSINSTAL Conventions 2.4 Running VMSINSTAL 2.5 Special Installation Considerations for DSVCONFIG.COM 2.6 Installing onto Alternate Load Hosts 2.6.1 Installing onto Single Systems 2.6.2 Installing onto VAXclusters 2.6.3 Installing onto Other Operating Systems 2.7 After Exiting VMSINSTAL 3. Configuring the Load Host's Node Database 3.1 Overview of DSVCONFIG 3.1.1 Databases Affected by DSVCONFIG 3.1.2 DSVCONFIG Options for the Software Installer 3.2 Specifying DECnet Characteristics During DSVCONFIG 3.2.1 DECnet Node Name 3.2.3 DECnet Node Address 3.2.3 Ethernet Address 3.2.4 Server Type 3.2.5 Load File (Server Image File) 3.2.6 Dump File Name 3.2.7 Service Circuit 3.3 Preparing to Run the Configuration Procedure 3.4 DSVCONFIG Conventions and Requirements 3.5 Running DSVCONFIG 3.5.1 List Known DECservers (Option 1) 3.5.2 Add a DECserver (Option 2) 3.5.3 Restore Existing DECservers (Option 5) 3.6 Restoring with the Restore Parameter and from Your Start-Up Procedure 3.7 Configuring on VAXcluster Nodes 3.7.1 Running DSVCONFIG for the First Time 3.7.2 Running This Version of DSVCONFIG Again 3.8 Exiting DSVCONFIG 3.9 After Exiting from DSVCONFIG 4. Verifying the Installation 4.1 Verifying the Load Host Installation 4.1.1 If You Are Loading a New Server 4.1.2 If You Are Loading an Existing Server 4.1.2.1 Loading During Off-Hours 4.1.2.2 Warning Users Before Loading 4.1.3 Down-Line Loading with the LOAD Command 4.1.3.1 Preparing for the LOAD Command 4.1.3.2 Issuing the LOAD Command 4.1.3.3 Using DECnet Event Logging 4.2 Verifying the Server System Installation A. DECserver 200 Distribution Files B. Using the Remote Console Facility C. Examples: Installation, Configuration, Verification C.1 Example of an Installation C.2 Example of a Configuration C.2.1 Starting DSVCONFIG.COM C.2.2 Listing Known Terminal Servers (Option 1) C.2.3 Adding a Terminal Server (Option 2) C.2.4 Swapping an Old Unit for a New Unit (Option 3) C.2.5 Deleting a Terminal Server from the Database (Option 4) C.2.6 Restoring Existing Terminal Servers to the Database (Option 5) C.3 Example of Verification: Verifying a Load Host Installation C.3.1 Using RCF and Warning Server Users C.3.2 Enabling DECnet Event Logging and Checking Server Names C.3.3 Down-Line Loading with the LOAD Command C.3.4 DECnet Event-Logging Display After Issuing LOAD C.3.5 Checking the Service Circuit C.3.6 Conclusion of a Load Host Installation Verification C.4 Example of Verification: Verifying the Server System Installation D. How to Report a Problem D.1 Submitting an SPR D.2 Reporting Documentation Problems D.3 Handling Severe Errors Preface This installation guide explains how to: o Install the DECserver 200 distribution software onto a VMS system running DECnet so that this system can then perform as a load host. The potential load host can be a single system or a member node of a VAXcluster. o Configure the load host's node database. o Verify the installation by first down-line loading the server image to the DECserver 200 unit and then testing a few server commands. Intended Audience This guide is intended for system managers or network managers who are responsible for making server products available on their Ethernets. A system manager is responsible for the VMS system that is about to be established as a load host. A network manager is the person responsible for the local area network (LAN). To use this guide effectively, you should be familiar with both DECnet network management concepts and the VMS operating system. Structure of This Manual This manual has four chapters and four appendixes: Chapter 1 Introduces the DECserver 200 product and summarizes the installation, configuration, and verification procedures. Chapter 2 Describes first how to prepare for the installation and then how to install the distribution software. Chapter 3 Explains how to configure the load host's node database. Chapter 4 Explains how to verify the installation by first down-line loading the server image and then testing a few server commands. Appendix A Lists the names of the files in the DECserver 200 distribution kit. Appendix B Discusses briefly the Remote Console Facility (RCF). Appendix C Contains examples of the installation and configuration procedures and examples of verification by down-line loading. Appendix D Contains instructions for reporting problems, if any occur during the installation. Other DECserver 200 Documents o Using DECserver 200 Manuals Directs you to information contained in the DECserver 200 documentation set. Flowcharts suggest logical reading sequences for different audiences. This document is intended for all users of the DECserver 200 documentation set. o DECserver 200 Management Guide Describes all the initial and day-to-day management tasks required of the DECserver 200 manager. The topics cover all the information needed to configure the ports and to customize the permanent and operational databases of the server. This guide is intended for the DECserver 200 manager. o DECserver 200 User's Guide Describes the user interface and the general functions of the server. This guide gives complete information for using all nonprivileged server commands. It is intended for users of interactive terminals connected to DECserver 200 ports. o Terminal Server User's Reference Card Describes on a reference card the most frequently used server commands. o DECserver 200 Hardware Installation/Owner's Manual Describes environmental requirements for the DECserver 200 unit and the installation of the hardware unit. This guide is intended for the hardware installer. o DECserver 200 Identification Card Provides the space to record identification information for the DECserver 200 unit. This document is intended for the network manager, the software installer, and the server manager. o Terminal Server Commands and Messages Describes the usage and syntax of all terminal server commands (privileged and nonprivileged). This guide also lists and describes all status and error messages issued by the server. This reference is intended for the server manager but is useful for terminal users who want more detailed reference information. o DECserver 200 Commands Mini-Reference Summarizes all privileged and nonprivileged server commands and characteristics in a pocket-size mini-reference. This reference is intended as a memory jog of command syntaxes for both privileged and nonprivileged users. o DECserver 200 Problem Determination Guide Describes the server's troubleshooting tools and procedures. It explains how to isolate server faults and how to repair the server to the field-replaceable unit level. This guide is intended for the server manager. o Terminal Server Glossary Defines terms used in server documentation. This document is intended as a reference tool for all users of server documentation. o DECserver 200 System Technical Manual Describes how the DECserver 200 system software and hardware components interact to perform server functions. This manual also describes the hardware specifications, the controls and indicators, and the diagnostics self-test program. Detailed descriptions of the hardware components are not included but are found in the hardware manual for the specific component. This manual is intended for training, field service, and manufacturing personnel. Associated Documents o LAT Network Concepts Guide Presents information about local area transport (LAT) and LAT networks. It discusses LAT concepts and definitions and provides guidelines to coordinate the configuration, performance, and troubleshooting of LAT servers and service nodes. o Guide to Terminal Server Manager and Terminal Server Manager Software Installation Guide Explain how to install and run the Terminal Server Manager (TSM) software, an optional network management product, which is installed onto a VMS system running DECnet-VAX. These guides describe how to use TSM to manage a mix of Digital Equipment Corporation Ethernet terminal servers connected to the same Ethernet as a VAX computer. These guides are intended for the installer and manager of the TSM software product. Note If you have the TSM software, read the documentation for this product before you look at the DECserver 200 documents. TSM affects the way you install and manage servers. Conventions Used in This Manual Familiarizing yourself with the conventions discussed in this section will help you use this manual effectively. The following conventions apply to numbers: o All numbers are decimal unless otherwise noted. o All Ethernet addresses are given in hexadecimal. Graphic Conventions Used in This Manual _________________________________________________________________________ Convention Meaning _________________________________________________________________________ Special type This special type in examples indicates system output or user input. System output is in black type; user input is in red type. UPPERCASE Uppercase letters in command lines indicate keywords that must be entered. You can enter keywords in either uppercase or lowercase. You can abbreviate command keywords to the smallest number of characters that distinguishes the keyword to the server or to the TSC. lowercase Lowercase italics in command syntax or examples italics system supplies a value. BOLD In summaries of characteristics, bold type indicates default values. bold In text, words appearing in bold type introduce new terms or concepts and can also be found in the glossary. [ ] Square brackets in command lines indicate that the enclosed value(s) are optional. You can enter none or one. Default values apply for unspecified options. Do not type the brackets. In the installation dialog, square brackets enclose default answers. To choose the default, press the RETURN key. To specify another value, type the answer after the question and press the RETURN key. Press the specified key. For example, means that you should press the RETURN key. Hold down the CONTROL key and then press the key specified by x. The server displays this key combination as ^x. 1 _____________________________________________ Introducing the DECserver 200 Terminal Server 1.1 What Is the DECserver 200 Terminal Server? The DECserver 200 terminal server is a hardware and software product that connects to an Ethernet local area network (LAN). The server connects as many as eight terminals (or other asynchronous port devices) to a LAN, allowing each device to communicate with the other nodes on that LAN. The software that you are about to install consists of the files in the DECserver 200 distribution kit. After you install the distribution software onto your system, you will configure your system's node database for all new servers. Next, you verify the installation by down-line loading one test server. Down-line loading means sending the server image from the established load host to the server. Finally, you issue a few server commands to test the server system. Installation requires the NET VMS, UTIL VMS, and VMS REQUIRED SAVESET tailoring classes. 1.2 DECserver 200 Concepts The DECserver 200 unit gives terminals access to all services of the LAN, supporting both direct and modem connections. 1.2.1 Connections Port devices can be connected directly to the server, or they can be connected remotely by using modems. The DECserver 200 unit also supports printers and connections to hosts that support EIA 232-D or asynchronous connections. With the DECserver 200/DL unit, terminals and printers can be attached with DECconnect cables. With the DECserver 200/MC unit, terminals and printers can be attached by using modem connections. 1.2.2 Services The DECserver 200 unit gives terminals access to services offered on the LAN. A service is a resource such as a computer. Each DECserver 200 user can maintain up to eight simultaneous connections to these various services. 1.2.3 Service Nodes and LAT Protocol Server users are offered services by service nodes. A service node is any node on the LAN that implements the local area transport (LAT) protocol. The server, in turn, uses the same LAT protocol to connect terminals to these services. LAT architecture uses Ethernet to make logical connections between terminals and service nodes on the same network. When connected to a service, a terminal appears to be connected directly to the service node. DECnet is not necessary for VMS systems to function as LAT service nodes. The DECserver 200 unit itself can be configured as a service node, offering printers, dial-out modems, and non-LAT host systems as services on the LAN. 1.2.4 LAT Software LAT V5.1 is implemented on a VMS node by LAT/VMS. This includes the LTDRIVER, which is a port driver in direct communication with the system's terminal class driver. LTDRIVER implements the protocol necessary to communicate with devices connected to the server and is used in place of a local port driver, such as the DZDRIVER. A LAT Control Program (LATCP) provides the command interface to the LTDRIVER. LATCP can be used to start and stop the driver as well as to set and to display characteristics of the driver. A network node does not need LAT to perform load-host functions, but LAT software is required for a system to offer services as a service node. On remote-access ports, the DECserver 200 unit permits VMS service nodes with this software to make requests for printers on server ports. These requests are called host-initiated requests. 1.3 Performing the Software Installation As a software installer, you are responsible for three tasks: 1. Installing the DECserver 200 distribution software 2. Configuring the load host's node database 3. Verifying the installation, which includes: - Verifying the load host installation by down-line loading the server image - Verifying the server system installation by testing a few server commands Completion of these tasks establishes your VMS system as a load host for one or more servers. A load host is a system that contains the server image and whose node database has entries for specific servers, and, as a result, can down-line load the server image to servers on the local Ethernet. In addition, a load host performs maintenance activities such as receiving up-line dumps from the server. A load host can be a single VMS system, or it can be a member node of a VAXcluster. For a VMS system to act as a load host, it must be running DECnet Phase IV, and it must be located on the same Ethernet as the server. For supported version numbers of DECnet software, see the Software Product Description for the DECserver 200 product. A load host must have 850 free blocks of disk space to install the DECserver 200 distribution files. Another 768 free blocks of disk space is required for each up-line dump. Load hosts are assigned by the network manager. Digital Equipment Corporation advises that you establish more than one system as a load host for each server. Alternate hosts free the server from dependence on one particular load host. For each server, Digital Equipment Corporation suggests a minimum of two load hosts. Digital Equipment Corporation also recommends one load host for every ten servers on a network. When selecting alternate load hosts, you can choose any Digital Equipment Corporation system for which a DECserver 200 distribution kit is available. DECserver 200 software distribution kits are available for these systems: o VMS V4.7 through V5.2 and MicroVMS V4.7 o RSX-11M-PLUS o Micro/RSX o ULTRIX-32 For information on installing the server distribution software onto another operating system and configuring that system's node database in order to establish it as an alternate load host, see the DECserver 200 software installation guide for that system. In addition to the three tasks just described, you must coordinate the total software installation procedure with both the server hardware installer of a new server and the server manager of an existing server. For example, the software should be installed before the hardware is powered up for the first time. Chapter 4 details the coordination necessary among you, the hardware installer, and the server manager. 1.3.1 Installing the DECserver 200 Distribution Software You install the server distribution software onto a VMS system with an automated procedure called VMSINSTAL. The DECserver 200 software distribution kit includes a procedure file that VMSINSTAL uses to do the installation. VMSINSTAL does the following: o Copies the files from the distribution media to the load host. o Creates the appropriate directory for these files. o Prints the DECserver 200 Release Notes. VMSINSTAL gives you three choices: (1) display the release notes, (2) print the release notes, or (3) display and print the release notes. See Chapter 2 for instructions on installing the distribution software. Note If you have the Terminal Server Manager (TSM) software V1.2 or later, an optional network management product available for VMS load hosts, read the documentation for this product before you install the DECserver 200 software. TSM affects the way you install and manage servers. 1.3.2 Configuring the Load Host's Node Database Once you copy the distribution software to your VMS system, you should configure the system's node database to support new servers. You configure this database with an automated procedure called DSVCONFIG. The DSVCONFIG configuration procedure file is part of the DECserver 200 software distribution kit. Configuration of the load host's node database means defining an entry for each server in three places: (1) a data file called DSVCONFIG.DAT, (2) the DECnet operational (also called "volatile") database, and (3) the DECnet permanent database. The DSVCONFIG.DAT file is the server configuration database. DSVCONFIG.DAT is automatically created by DSVCONFIG and is part of a load host's node database. When you use DSVCONFIG to configure a new server, DSVCONFIG automatically adds an entry in the three places mentioned above. The entry identifies the: o Server type o Server's DECnet node name and DECnet node address o Server's service circuit-ID o Server's Ethernet address o Server image When you complete the configuration procedure, your VMS system is established as a load host for each server that has an entry in the node database. See Chapter 3 for instructions on configuring the load host's node database to support servers. To configure a server on a VAXcluster, install the distribution software onto one member node and then configure the node databases of the members that you want to establish as load hosts. See Section 3.7 for details. Besides allowing you to configure a new server in the load host's node database, DSVCONFIG allows you to list all servers currently defined in the DSVCONFIG.DAT file and to restore to the host's DECnet databases all server configurations defined in DSVCONFIG.DAT. Chapter 3 explains how to use these options. Appendix C has examples showing how to use these and two other options: (1) Replacing an existing DECserver unit with a new DECserver 200 unit (or changing the characteristics of an existing unit), and (2) removing a DECserver 200 unit from the node database. Normally you do not use these latter two options during the installation procedure. The DECserver 200 Management Guide explains how to use them. 1.3.3 Verifying the Installation After configuring the node database, your final responsibility is to verify the installation. Actually, you need to perform two verifications: 1. To verify the installation of the load host, down-line load the server image to a server, and then read the DECnet event-logging messages. Verifying the installation of the load host means checking that this load host: - Has the appropriate files in the correct directory. - Has a correct entry in its node database for the test server. - Can successfully down-line load the server image. 2. To verify the total server system installation, test a few server commands at an interactive terminal connected to a server port. Verifying the system installation means checking that: - The correct version of the software is in the server. - The server hardware operates with the new software. - The new software is running successfully. 1.3.3.1 Verifying the Load Host Installation To verify that your VMS system has been successfully established as a load host, use it to perform a down-line load. Down-line loading means sending the server image from an established load host to the server. Use the NCP LOAD NODE command from your VMS load host to down-line load. Then, check the DECnet event-logging messages in order to verify that the load was successful. 1.3.3.2 Verifying the Server System Installation Using a few server commands at an interactive terminal attached to a server port completes your verification of the server system installation. See Chapter 4 for details on the two verification procedures. See Appendix A for a list of the DECserver 200 distribution files. See Appendix B for a brief discussion of the Remote Console Facility. Finally, see Appendix C for step-by-step examples of the entire software installation. 2 __________________________________________________ Installing the DECserver 200 Distribution Software This chapter describes how to prepare for installation and how to install the DECserver 200 distribution software onto your VMS load host. To install the software, use VMSINSTAL.COM, an automated procedure, which is part of the VMS operating system. 2.1 Overview of VMSINSTAL VMSINSTAL is an interactive procedure that calls and controls the DECserver 200 installation procedure. VMSINSTAL performs the following tasks: o Creates a directory called SYS$SYSROOT:[DECSERVER] on the load host, if necessary o Copies the files from the distribution media into this directory o Prints a copy of the DECserver 200 Release Notes when you specify OPTIONS N 2.2 Preparing to Run the Installation Procedure Before you actually run VMSINSTAL, follow these steps: 1. Determine which systems are designated as load hosts for the server. You must install the distribution software onto all of these systems. Ask your network manager or the person responsible for assigning load hosts to tell you which are the designated systems. Note that you do not need a separate license for each load host, but you do need a separate license for each server. 2. Check that there are 850 free blocks of disk space on each load host for copying the distribution files. Another 768 free blocks of disk space is required for each up-line dump. Ensure that the network and utility classes are tailored on the load host. 2.3 VMSINSTAL Conventions VMSINSTAL is an interactive procedure. When you start VMSINSTAL, a series of questions displays. After each question, the default response, if there is one, displays in square brackets ( [ ] ). At the end of each question, either a colon (:) or a question mark (?) appears. o To answer a question, type your response immediately after the colon or question mark; then press the RETURN key. o To respond to a question with the default answer, press only the RETURN key. o To get help after any question, type a question mark (?). After the help display, the question is repeated. See the VMS documentation for a complete description of VMSINSTAL. 2.4 Running VMSINSTAL Running VMSINSTAL.COM requires the appropriate privileges. To determine what they are, see the system manager. Run VMSINSTAL.COM from the system manager's account. The installation procedure takes approximately 10 to 15 minutes. Follow these steps: 1. Place the distribution medium on the appropriate device drive. 2. Log in to the system manager account. 3. Start VMSINSTAL with these commands: $ SET DEFAULT SYS$UPDATE $ @VMSINSTAL DS2 device-identifier OPTIONS N Here, DS2 is the VMS three-letter facility code for the DECserver 200 product and device-identifier is the device on which the distribution medium is mounted. OPTIONS N tells VMSINSTAL to ask you, during the procedure, if you want to print the DECserver 200 Release Notes. Note Digital Equipment Corporation recommends that you specify OPTIONS N on the command line. See the VMS documentation set if you do not want to print the release notes, or if you are interested in VMSINSTAL's other options. If you are installing onto alternate load hosts with copied savesets, the VMSINSTAL command line format differs slightly. See the VMS documentation on VMSINSTAL. VMSINSTAL displays the procedure title and the date and time. It continues with the following (the warning message appears only if DECnet is running): %VMSINSTAL-W-DECNET, Your DECnet network is up and running. * Do you want to continue anyway [NO]? 4. Type YES and press the RETURN key to proceed with the installation. 5. VMSINSTAL asks: * Are you satisfied with the backup of your system disk [YES]? 6. If you answer NO, the installation procedure terminates. Take appropriate action and start the procedure again. If the backup is satisfactory, press the RETURN key to answer YES. 7. If you are installing from the distribution media rather than from copied savesets, VMSINSTAL prompts you to mount the first volume: Please mount the first volume of the set on device-identifier. * Are you ready? Type YES and press the RETURN key. A confirmation message says that the medium is mounted. 8. The procedure continues: The following products will be processed: DS2 Vn.n Beginning installation of DS2 Vn.n at hh:mm %VMSINSTAL-I-RESTORE, Restoring product saveset A... Note DECserver 200 software version numbers are not specified in this manual. For example, the release notes file is shown as DS2_nnn.RELEASE_NOTES. Here, nnn represents the version number; if you are installing Version 3.0, the release notes file is DS2030.RELEASE_NOTES. 9. Some types of distribution media require several volumes. (More than one distribution medium is delivered with your distribution kit.) For these types of distribution media, the procedure gives you a continuation message and tells you to mount the next volume (each volume is labeled with a volume number): %BACKUP-I-READYREAD, mount volume 2 on device-identifier: for reading Enter "YES" when ready: Mount the next volume, type YES, and press the RETURN key. 10. The procedure lists your options for printing and displaying the release notes: Release Notes Options: 1. Display Release Notes 2. Print Release Notes 3. Both 1 and 2 * Select option [3]: Select one of these options. Digital Equipment Corporation recommends that you select Option 2. - If you select Option 1, you see: VMI$ROOT:[SYSUPD.DS2nnn]DS2nnn.RELEASE_NOTES;1 The release notes immediately start scrolling at your terminal. Note The release notes might contain up to 30 pages. - If you select Option 2, VMSINSTAL asks you which queue you want to send the file to for printing: * Queue name [SYS$PRINT]: Press the RETURN key to print the release notes on the default printer, or specify another print queue. A message indicates that the system queued the file. - If you select Option 3, VMSINSTAL first asks you which queue you want to send the file to for printing: * Queue name [SYS$PRINT]: Press the RETURN key to print the release notes on the default printer, or specify another print queue. A message indicates that the system queued the file for printing. Next, VMSINSTAL displays the release notes: VMI$ROOT:[SYSUPD.DS2nnn]DS2nnn.RELEASE_NOTES;1 The release notes immediately start scrolling at your terminal. 11. After the system's queue message and the release notes are displayed (if you selected one of the display options), the procedure continues by asking: * Do you want to continue the installation [N]? Press the RETURN key to stop the procedure and review the release notes. Check for any changes that can affect this installation. (VMSINSTAL places the release notes file, DS2nnn.RELEASE_NOTES, in the SYS$HELP directory.) 12. Run the procedure again when you are ready to continue. Enter this form of the command: $ @VMSINSTAL DS2 device-identifier 13. VMSINSTAL displays the procedure title and the date and time. It continues with the following (the warning message appears only if DECnet is running): %VMSINSTAL-W-DECNET, Your DECnet network is up and running. Do you want to continue anyway [NO]? Type YES and press the RETURN key to proceed with the installation. 14. VMSINSTAL asks: * Are you satisfied with the backup of your system disk [YES]? Press the RETURN key to answer YES. 15. If you are installing from the distribution media rather than from copied savesets, VMSINSTAL prompts you to mount the first volume: Please mount the first volume of the set on device-identifier. * Are you ready? * Type YES and press the RETURN key. 16. A confirmation message says that the medium is mounted. The procedure continues: The following products will be processed: DS2 Vn.n Beginning installation of DS2 Vn.n at hh:mm %VMSINSTAL-I-RESTORE, Restoring product saveset A... %VMSINSTAL-I-RELMOVED, The product's release notes have been successfully moved to SYS$HELP. * * Do you want to run the IVP after the installation [YES]? 17. If your distribution media require more than one volume, the procedure gives you a continuation message and tells you to mount the next volume. Each volume is labeled with a volume number. %BACKUP-I-READYREAD, mount volume 2 on device-identifier: for reading Enter "YES" when ready: Mount the next volume, type YES, and press the RETURN key. 18. If you are on a VAXcluster node, the following message displays: If you intend to execute this layered product on other nodes in your VAXcluster, and you have the appropriate software license, you must prepare the system-specific roots on the other nodes by issuing the following command on each node (using a suitably privileged account): $ CREATE/DIRECTORY SYS$SPECIFIC:[DECSERVER]/PROTECTION=(S:RWED,O:RWED) 19. You have finished the first part of the installation. The procedure continues: - It tells you that the installation is complete, meaning that the distribution files have all been copied to their appropriate directories. (See Appendix A for descriptions of the DECserver 200 VMS distribution files.) - It instructs you how to continue. - It mentions the additional software you must install at this time. Your installation is now complete. After exiting from VMSINSTAL: 1. Edit your system start-up file so that it defines the logical MOM$LOAD as a search string with a value equal to the current search string plus the added element SYS$SYSROOT:[DECSERVER]. For example: DEFINE/SYSTEM/EXEC/NAME_ATTRIBUTE=NO_ALIAS/NOLOG - MOM$LOAD 'current-search-string',SYS$SYSROOT:[DECSERVER] If the current search string associated with MOM$LOAD in your start-up file is SYS$SYSROOT:[DECSERVER] or if you have already made this change for a previous installation, there is no need to edit this file. This command ensures that the location of the server image is defined each time the system is rebooted, necessary for successful down-line loading. 2. Configure the server into your host's database. Execute a command procedure called DSVCONFIG.COM. This command procedure is in the SYS$SYSROOT:[DECSERVER] directory. If you have already executed this procedure from previous installations, you need to configure only any additional units. All previously defined units will still be configured. 3. The Installation Verification Procedure (IVP) for the DECserver 200 can be found in SYS$TEST and may be run at any time by executing the command procedure DS2$IVP.COM. 20. VMSINSTAL runs the Installation Verification Procedure: %VMSINSTAL-I-RESTORE, Restoring product saveset B... %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories ... Beginning installation verification procedure for DECserver 200 Vn.n. Successfully located SYS$SYSROOT:[DECSERVER] directory Successfully located SYS$SYSROOT:[DECSERVER]DS2nnn.RELEASE_NOTES Successfully located SYS$SYSROOT:[DECSERVER]PR0801ENG.SYS Successfully located SYS$SYSROOT:[DECSERVER]DSVCONFIG.COM Successfully located SYS$SYSROOT:[DECSERVER]DSVCONFIG.DAT Successfully located SYS$SYSROOT:[DECSERVER]DS2_nnn_DEFAULTS.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_ADD_ LOCAL_SERVICE.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_CTS_RTS_ PRINTER.COM Sucessfully located SYS$SYROOT:[DECSERVER]TSM$DS2_nnn_DEDIC_SERV_ PRINTER.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DEDIC_ SERV_TERM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DIAL_IN_ MODEM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DIAL_ IN_OUT_MODEM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DIAL_OUT_ MODEM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DSR_DTR_ TERM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_GET_ CHAR.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_HOST_ INIT_PRINTER.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_NON_ LAT_HOST.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_PC_TERM_ OR_SERV.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_PORT_ DEFAULT.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_TERM_ SWITCH.COM Installation verification procedure for DECserver 200 Vn.n successful. Installation of DS2 Vn.n completed at nn:nn VMSINSTAL procedure done at nn:nn $ Note If you are installing files onto a VAXcluster node, the messages indicate that the files are copied to the SYS$COMMON:[DECSERVER] directory. MOM$LOAD is a logical name that your load host uses to find the image file of any product that must be down-line loaded. For each product, MOM$LOAD has an associated equivalence string that specifies the location of the product's image file. Thus, the following command equates the logical name MOM$LOAD to the location of your DECserver 200 image file: DEFINE/SYSTEM/EXEC/NAME_ATTRIBUTE=NO_ALIAS/NOLOG MOM$LOAD - SYS$SYSROOT:[DECSERVER] If your system is a load host for several products, then the location of each image file must be defined by a list of equivalence strings. For example, the following command defines the location of a LAN Bridge image file as well as the DECserver 200 image file: DEFINE/SYSTEM/EXEC/NAME_ATTRIBUTE=NO_ALIAS/NOLOG MOM$LOAD - SYS$SYSTEM:[MOM$SYSTEM],SYS$SYSTEM:[DECSERVER] Two or more equivalence strings make up a search list. When your VMS system is requested to down-line load a product, it looks through the search list until it finds the location of the product's image file. Your host cannot down-line load the DECserver 200 image file unless the search list defined for MOM$LOAD has the correct location of the image file. To see what the current search string is for MOM$LOAD, use the DCL SHOW LOGICAL command: $ SHOW LOGICAL MOM$LOAD If SYS$SYSROOT:[DECSERVER] is defined for MOM$LOAD, you do not have to define MOM$LOAD. Define MOM$LOAD only if: - No equivalence string exists for MOM$LOAD (the SHOW LOGICAL command results with the message "No translation for logical name MOM$LOAD"). or - The equivalence strings defined for MOM$LOAD do not include SYS$SYSROOT:[DECSERVER]. If MOM$LOAD is already defined for other products but not for the DECserver 200 product, you must define MOM$LOAD by specifying SYS$SYSROOT:[DECSERVER] along with the current search string(s), as shown in the VMSINSTAL example. If you specify only SYS$SYSROOT:[DECSERVER] for MOM$LOAD excluding the current search string(s), then SYS$SYSROOT:[DECSERVER] will replace the current search string(s). Your VMS system will not be able to load the image files located by the current search string(s). 21. Depending on your system, VMSINSTAL may now let you make an entry in the Software History log. The procedure concludes: VMSINSTAL procedure done at hh:mm $ See Section 2.7 for the next step. 2.5 Special Installation Considerations for DSVCONFIG.COM The configuration command procedure, DSVCONFIG.COM, which is part of this distribution kit, accommodates the DECserver 100, DECserver 200, and DECserver 500 products. However, some previous releases of DSVCONFIG.COM cannot accommodate the DECserver 500 product. Therefore, for all configurations use the command file on your kit only. When installing new versions of DECserver products, always check the product release notes for information on the latest DSVCONFIG.COM. 2.6 Installing onto Alternate Load Hosts Digital Equipment Corporation recommends that you establish alternate load hosts for each server. Alternates free the server from dependence on one particular load host because an alternate load host can perform a down-line load if the original load host is unavailable. In addition, alternate load hosts can receive up-line dumps from servers. Regarding the assignment of load hosts, Digital Equipment Corporation suggests both the following: o For each server, at least one other load host as a backup to the original o At least one load host for every ten servers As with the original load host, an alternate VMS load host must: o Be running DECnet o Have an Ethernet controller on the same Ethernet as the server o Have the distribution software installed o Have DECserver 200 entries in its server configuration database (DSVCONFIG.DAT file), the DECnet operational database, and the DECnet permanent database o Have the latest load file (see Chapter 3) o Have its Ethernet circuit enabled for service 2.6.1 Installing onto Single Systems To install the server distribution software onto an alternate VMS load host that is not a member of a VAXcluster, use one of these methods: o If the alternate load host has the same load device as the original host, place your distribution media on the appropriate device of the new load host and repeat the installation procedure detailed in Section 2.4. o If the alternate load host does not have the same load device as the original host, load and extract the savesets from the kit, using the following procedure: - Type the following command on the original load host: $ SET DEFAULT SYS$UPDATE: $ @VMSINSTAL DS2 device-identifier OPTIONS G SYS$UPDATE: Here, DS2 is the VMS three-letter facility code for the DECserver 200 product. OPTIONS G extracts the savesets from the kit. - Copy the savesets to the alternate load host's SYS$UPDATE directory. The savesets are DS2nnn.A and DS2nnn.B. - Run VMSINSTAL on the alternate load host: $ @VMSINSTAL DS2 SYS$UPDATE: 2.6.2 Installing onto VAXclusters To install the server distribution software onto an alternate load host that is a member of a VAXcluster, follow these steps: 1. Run DSVCONFIG on all cluster members that are to act as load hosts. (Do not reinstall the software on homogeneous clusters.) The software is installed onto the common cluster disk. Since the distribution files are in SYS$COMMON:[DECSERVER], all cluster members have access to them. 2. Follow the steps in Section 3.7 to keep accurate each member's three databases for servers. 2.6.3 Installing onto Other Operating Systems To install the DECserver 200 distribution software onto an operating system other than VMS, follow the instructions in the DECserver 200 Software Installation Guide for that system. You can find the guide for one of the other supported operating systems in the software distribution kit for that operating system. Or you can separately order any DECserver 200 Software Installation Guide for another operating system. 2.7 After Exiting VMSINSTAL After you exit VMSINSTAL, follow these steps: 1. Check the DECserver 200 Release Notes to see if you have to install any additional software from the distribution media. If so, install those distribution files. 2. Give the DECserver 200 Release Notes to the server manager. 3. Run the configuration procedure, DSVCONFIG.COM, to configure the load host's node database. See Chapter 3 for information about this procedure. 3 __________________________________________ Configuring the Load Host's Node Database This chapter explains how to configure a VMS load host's node database for new servers. Configuring this database is part of the software installation. After this procedure, your VMS system is established as a valid load host for the new servers. To configure the load host's node database for a new server, use the Add option of DSVCONFIG.COM, an automated, menu-driven procedure. DSVCONFIG.COM prompts you for information about the new server and then configures the load host's node database by adding an entry for the new server to the DSVCONFIG.DAT file (the server configuration database) and the DECnet databases. You also can configure the load host's node database by restoring to the DECnet databases the server entries that exist in the DSVCONFIG.DAT file. If you ran the installation procedure described in Chapter 2, DSVCONFIG.COM is now in the SYS$SYSROOT:[DECSERVER] directory for single systems and in SYS$COMMON:[DECSERVER] for VAXcluster members. The load host creates and maintains all server-related files in this directory. Note DSVCONFIG.COM, which is part of this distribution kit, accommodates the DECserver 100, DECserver 200, and DECserver 500 products. However, some previous releases of DSVCONFIG.COM do not accommodate the DECserver 500 product. Therefore, use the command file on this kit for all configurations. 3.1 Overview of DSVCONFIG DSVCONFIG has five configuration options, all of which affect the node database on the load host. When you start the DSVCONFIG procedure, it displays the following menu of options: DECserver Configuration Procedure Version: V1.7 Menu of Options 1 - List known DECservers 2 - Add a DECserver 3 - Swap an existing DECserver 4 - Delete an existing DECserver 5 - Restore existing DECservers CTRL/Z - Exit from this procedure To configure your load host's node database for new servers, use the List and Add options. You may also need to use the Restore option (especially for configuring VAXcluster nodes). This chapter discusses these three options only. The Swap and Delete options are used by the server manager. The Swap option is recommended for use when the server hardware unit malfunctions and must be replaced. The Delete option is useful when reconfiguring the network or changing load hosts for a server. Examples showing the use of these options are included in Appendix C. For more information on these options and DSVCONFIG, see the DECserver 200 Management Guide. This chapter first discusses the databases that the DSVCONFIG options affect. Subsequent sections explain how to: o Specify DECnet characteristics during DSVCONFIG (Section 3.2) o Prepare for running DSVCONFIG (Section 3.3) o Respond to DSVCONFIG and comply with its requirements (Section 3.4) o Start DSVCONFIG and use the List, Add, and Restore options (Section 3.5) o Start DSVCONFIG with the RESTORE parameter to restore your local DECnet database (Section 3.6) o Configure VAXcluster nodes using DSVCONFIG (Section 3.7) o Exit from DSVCONFIG (Section 3.8) See the DECserver 200 Management Guide for a complete description of DSVCONFIG. 3.1.1 Databases Affected by DSVCONFIG The DSVCONFIG procedure operates on three distinct databases contained in the load host's node database: 1. The server configuration database for servers. This database is stored in the file DSVCONFIG.DAT. It has the information you see when you select Option 1, List, from the DSVCONFIG Menu. 2. The operational host DECnet database. 3. The permanent host DECnet database. When you run DSVCONFIG, server information is transferred from the DSVCONFIG database to the DECnet database. These two databases must remain synchronized. The DSVCONFIG procedure automatically keeps these databases synchronized on the load host. Though DSVCONFIG includes several NCP commands, do not execute these commands yourself to configure the load host's node database. NCP affects only the DECnet databases. On a VAXcluster load host, the DSVCONFIG procedure automatically synchronizes the databases on the load host but not on the other members of the VAXcluster. Section 3.7 explains how to configure VAXcluster nodes so that the databases are synchronized on all members. 3.1.2 DSVCONFIG Options for the Software Installer As a software installer, you use the List, Add, and Restore DSVCONFIG options for new servers. 1. List known DECservers - Lists servers that are currently defined in DSVCONFIG.DAT. 2. Add a DECserver - Adds an entry for a new server in DSVCONFIG.DAT and in the DECnet databases. Adding an entry supplies information that identifies the server on the Ethernet and, thus, establishes this system as a load host for the new server. 3. Restore existing DECservers - Restores servers that exist in the DSVCONFIG.DAT file to the load host's DECnet operational database and DECnet permanent database. This option copies server entries from DSVCONFIG.DAT to the DECnet databases. For example, if the load host system is brought down, server entries may not be automatically restored to the DECnet databases when the system comes up again, especially if a central node database is used with NCP. Because server entries remain intact in the DSVCONFIG.DAT file, you can use the Restore option to copy these server entries to the DECnet databases. 3.2 Specifying DECnet Characteristics During DSVCONFIG Several DECnet characteristics apply to servers. DECnet uses these characteristics for down-line loading and up-line dumping. For each new server, you must specify some of the following characteristics; DSVCONFIG supplies the load file and dump file name automatically. _____________________________________________________________________ DECnet Characteristic You Specify DSVCONFIG Supplies _____________________________________________________________________ DECnet node address X DECnet node name X Server type X Service circuit-ID X Ethernet address X Load file X Dump file name X _____________________________________________________________________ The DECserver 200 information that you must specify is recorded on each unit's DECserver 200 Identification Card. Ask the hardware installer or the network manager for this card. 3.2.1 DECnet Node Name Each DECserver 200 unit must have a unique DECnet node name. This name must have from 1 to 6 alphanumeric characters with at least one character being an alphabetic character. For example, DSV5 and LION77 are valid DECnet node names. The network manager assigns DECnet node names. During the hardware installation, the hardware installer records the DECnet node name on the DECserver 200 Identification Card for each server. DSVCONFIG does not set up the server name on the server itself. The server name, a server characteristic stored in the server's databases, must be defined on the server by the server manager. To avoid confusion, the server name should match the DECnet node name. 3.2.3 DECnet Node Address Each DECserver 200 unit has a unique DECnet node address. This number must be a decimal number from 1 to 1023. If your DECnet network is divided into areas, each DECnet node address takes the form aa.nnnn. Here, aa is a decimal area number from 2 to 63, nnnn is the node address, and the period distinguishes area from address. For example, 17.1003 is a valid node address. The network manager assigns DECnet node addresses. During the hardware installation, the hardware installer records the DECnet node address on the DECserver 200 Identification Card for each server. 3.2.3 Ethernet Address Each DECserver 200 unit is delivered with a unique Ethernet hardware address. This address is six pairs of hexadecimal digits with a hyphen (-) separating each pair. For example, 08-00-01-00-AB-CD is an address with a valid format. The Ethernet address is on the control/indicator panel of the DECserver 200 unit. During the hardware installation, the hardware installer records the Ethernet address on each unit's DECserver 200 Identification Card. 3.2.4 Server Type The server type that you specify is "DS200," which defines your unit as a DECserver 200 server. 3.2.5 Load File (Server Image File) The DECserver 200 load file is the server's software image that is down-line loaded by the host to the server. You do not have to supply this information. The name of the DECserver 200 load file is PR0801ENG.SYS. 3.2.6 Dump File Name Each server has a unique dump file name, DS2node-name.DMP. Here, node-name is the DECnet node name of the server. For example, a DECserver 200 unit with the DECnet node name TIGER has the dump file name DS2TIGER.DMP. You do not have to supply the dump file name. When you use the Add option to define a new DECserver 200 unit, DSVCONFIG assigns a name for the dump file. See the DECserver 200 Problem Determination Guide for information on up-line dumping, the creation of the server's up-line dump file, and for using this file for problem analysis. 3.2.7 Service Circuit The service circuit is the Ethernet circuit that the load host uses to reach the server when loading and dumping occur. The load host may have more than one active Ethernet circuit, so you have to specify the service circuit-ID to identify which circuit is to be used for loads and dumps. The service circuit-ID is stored in the load host's DECnet databases. DSVCONFIG prepares your node as a load host by enabling SERVICE on the service circuit. SERVICE must be enabled before a down-line load can occur. _____________________________________________________________________ Service Circuit-ID Ethernet Controllers _____________________________________________________________________ UNA-n DEUNA UNA-n DELUA QNA-n DEQNA BNA-n * DEBNT BNT-n DEBNT SVA-n DESVA Here, n is an integer (typically 0 or 1). * BNA-n replaces BNT-n in VMS Version 5.0. _____________________________________________________________________ When you run DSVCONFIG to add more than one unit, the procedure asks you to specify the service circuit each time. The first time you are asked, the default is the service circuit for the processor type of your VMS load host. If you respond by specifying a different service circuit, that response becomes the default until either you specify another service circuit or you exit the procedure. The possible default values for each load host's CPU type are: _____________________________________________________________________ CPU Type Service Circuit-ID _____________________________________________________________________ VAX-11/780, 782, 785 UNA-0 VAX-11/730,750 UNA-0 VAX 8600, 8650 UNA-0 VAX 8200, 8300, 8500, UNA-0 or BNT-0 8550, 8700, 8800 MicroVAX II QNA-0 VAXstation II QNA-0 MicroVAX 2000 SVA-0 VAXstation 2000 SVA-0 _____________________________________________________________________ If your CPU supports more than one Ethernet controller, you can choose a service circuit-ID number other than zero. 3.3 Preparing to Run the Configuration Procedure Before beginning the configuration procedure: 1. Check that DECnet is installed and running. For information about DECnet, see the VMS documentation set. 2. Check that all the distribution software was installed in these directories: - SYS$SYSROOT:[DECSERVER] for single systems - SYS$COMMON:[DECSERVER] for VAXclusters See Appendix A for a list of the distribution files. 3. Check that each new server's DECnet node name and node address are unique. Ask the hardware installer for the DECserver 200 Identification Card for each new DECserver 200 unit. The network manager and the hardware installer recorded the server's DECnet node name and node address as well as the Ethernet address on this card. You need to know the server's DECnet node name, DECnet node address, and Ethernet address to answer prompts during DSVCONFIG. You can check the uniqueness of the server's DECnet node address and node name by specifying the address or name with the NCP SHOW NODE command: $ MCR NCP NCP>SHOW NODE node-name CHARACTERISTICS or NCP>SHOW NODE node-number CHARACTERISTICS If NCP shows a node already defined, see the network manager to resolve the conflict in names. 3.4 DSVCONFIG Conventions and Requirements DSVCONFIG is an interactive procedure. When you start DSVCONFIG, a menu of options displays. Within the Add option, you get a series of questions. After each question, the default response, if there is one, displays in brackets ([ ]). At the end of each question, either a colon (:) or a question mark (?) appears. The following list tells you how to use DSVCONFIG: o To select an option, type a menu number and press the RETURN key. o To answer a question, type your response immediately after the colon or question mark, and press the RETURN key. o To respond to a question with the default answer, press only the RETURN key. o To get help after any question, type a question mark (?). After the help display, the question is repeated. o To exit an option without making any changes, type . You are returned to the DSVCONFIG Menu. o To exit DSVCONFIG at the menu level, type. You are returned to the DCL prompt. DSVCONFIG has some additional conventions and requirements: o When you finish an option, DSVCONFIG automatically returns you to the DSVCONFIG Menu. o At the end of the Add option, you might get NCP messages (information, confirmations, and errors). In the case of error messages, the operation might not have been successful. For the meanings of these messages, see the VMS documentation set. o To run DSVCONFIG on a particular VMS load host, the distribution software must already be installed onto that system. 3.5 Running DSVCONFIG To run DSVCONFIG.COM, you need OPER and SYSPRV privileges. To start DSVCONFIG: 1. Log in to the system account or any account with OPER and SYSPRV privileges. 2. Enter the following commands: $ SET DEFAULT MOM$LOAD $ @DSVCONFIG Note The latter command assumes you have defined MOM$LOAD to locate the DECserver 200 software image in SYS$SYSROOT:[DECSERVER]. See Section 2.4. DSVCONFIG starts with these actions: o It determines whether the DECnet key is installed. If DECnet is missing, DSVCONFIG prints a message and exits. You must have DECnet to run this procedure. o It checks the existence and format of a data file called DSVCONFIG.DAT. It finds one of three possible situations and continues accordingly: - The DSVCONFIG.DAT file does not exist in the directory SYS$SYSROOT:[DECSERVER]. The procedure creates the DSVCONFIG.DAT file and displays a message telling you that the file was not found and a new one was created. - SYS$SYSROOT:[DECSERVER] already has this file, formatted correctly. This is the case if DSVCONFIG was previously used to add DECserver 200 entries. The procedure continues with its next task. - SYS$SYSROOT:[DECSERVER] (or for VAXclusters, SYS$SPECIFIC:[DECSERVER]) already has this file, but not in the correct format. The procedure reformats the file. Regarding VAXclusters, SYS$SPECIFIC:[DECSERVER] on each VAXcluster node may have an older version of the DSVCONFIG.DAT file. The DSVCONFIG procedure copies the server entries from that data file into the DSVCONFIG.DAT file on SYS$COMMON:[DECSERVER], a directory shared by the VAXcluster nodes. The procedure renames the DSVCONFIG.DAT file in SYS$SPECIFIC so that the DSVCONFIG.DAT file in SYS$COMMON is used thereafter. Note On VAXclusters, DSVCONFIG creates and writes files in the common area, SYS$COMMON:[DECSERVER]. See Section 3.7 for special i nstructions on running DSVCONFIG for the first time on VAXclusters. - It informs you that each DECserver unit must have a unique DECnet node name and DECnet node address. - It asks you either to continue or to exit: Press to start, or to exit... Press the RETURN key if you have the information you need for each new server. 3. DSVCONFIG displays: DECserver Configuration Procedure Version: V1.7 Menu of Options 1 - List known DECservers 2 - Add a DECserver 3 - Swap an existing DECserver 4 - Delete an existing DECserver 5 - Restore existing DECservers CTRL/Z - Exit from this procedure Your selection? Type the number of the option you want. Then press the RETURN key. 3.5.1 List Known DECservers (Option 1) Select Option 1 to list the DECservers in the DSVCONFIG.DAT data file. Type 1 and press the RETURN key. The contents of the DSVCONFIG.DAT file displays in seven columns. Option 1 displays a listing such as this: DECnet DECnet Server Service Address Name Type Circuit Ethernet Address Load File Dump File ------- ---- ---- ------- ---------------- ----------- ----------- 28.900 BUNNY DS200 BNT-0 08-00-2B-02-F0-99 PR0801ENG.SYS DS2BUNNY.DMP 28.1001 BACH DS200 UNA-0 08-00-2B-02-24-CC PR0801ENG.SYS DS2BACH.DMP 28.1002 BEETHO DS200 UNA-0 08-00-2B-03-AA-2B PR0801ENG.SYS DS2BEETHO.DMP 28.1003 MOZART DS100 UNA-0 08-00-2B-02-24-DD PS0801ENG.SYS PSDMP24DD.SYS 28.1005 HAYDN DS200 UNA-1 08-00-2B-03-AA-F1 PR0801ENG.SYS DS2HAYDN.DMP 28.1019 OCELOT DS500 UNA-0 08-00-2B-03-EE-FF DS5OCELOT.SYS DS5OCELOT.DMP 28.1022 JAGUAR DS500 UNA-0 08-00-2B-03-E1-F1 DS5JAGUAR.SYS DS5JAGUAR.DMP 28.1023 BEATLE DS100 UNA-0 08-00-2B-02-24-2D PS0801ENG.SYS PSDMP242D.SYS Total of 8 DECservers defined. (Press RETURN for menu) 3.5.2 Add a DECserver (Option 2) Select Option 2 to add an entry for a new server in the server configuration database (DSVCONFIG.DAT), the DECnet operational database, and the DECnet permanent database. To create an entry, you must supply: o The DECserver type o A unique DECnet node name for the DECserver unit o A unique DECnet node address for the DECserver unit o The Ethernet address of the DECserver unit o The service circuit To add a server, follow these steps: 1. Type 2 and press the RETURN key. 2. DSVCONFIG asks: DECserver type? Type DS200 and press the RETURN key. 3. DSVCONFIG asks: DECnet node name for unit? Specify the DECnet node name for the new server. 4. DSVCONFIG asks: DECnet node address for unit? Specify the DECnet node address for the new server. 5. DSVCONFIG asks: Ethernet address of unit? Specify the Ethernet address of the new server. 6. DSVCONFIG asks: * DECnet Service Circuit-ID [default-id]? * Press the RETURN key if the default service circuit is the same as the circuit that connects the load host to the same Ethernet as the server. If not, specify the service circuit-ID of the desired Ethernet controller: - UNA-n for DEUNA or DELUA - QNA-n for DEQNA - BNA-n* for DEBNT - BNT-n for DEBNT - SVA-n for DESVA Here, n is an integer (typically 0 or 1). See Section 3.2.7 for a discussion of service circuits. * BNA-n replaces BNT-n in VMS Version 5.0. DSVCONFIG adds the entry for the new server to the databases and sets SERVICE ENABLED on the specified service circuit, both of which are necessary for down-line loading. Caution If you get an error from DECnet while you are adding a server, the entry is added to the DSVCONFIG.DAT file even though it is not entered in the DECnet databases. To correct this synchronization problem, follow these steps: 1. Use Option 4 to delete the entry. (See the example in Appendix C, or refer to the DECserver 200 Management Guide.) 2. Fix the condition causing the DECnet error. 3. Return to Option 2 to add the server again with the correct information. If you specify a node address that is already defined in DSVCONFIG.DAT, you get a DSVCONFIG error, nothing is added, and the Add option is terminated. 3.5.3 Restore Existing DECservers (Option 5) Select Option 5 to restore your system's DECnet databases to include the servers in DSVCONFIG.DAT. The Restore option affects both the operational and permanent DECnet databases. It performs NCP SET and NCP DEFINE commands. If your DECnet network contains a large number of nodes, you might store your DECnet database on a central remote node and copy this database upon each system startup. However, if many servers exist on the network, Digital Equipment Corporation advises against defining these servers in that central database. If servers are not defined in the central database, you must restore them whenever you copy your local DECnet database from the central DECnet database. Each time you copy the central DECnet database, use Option 5 to restore existing server configurations. Type 5 and press the RETURN key. The following messages confirm the restoration: Restoring existing DECservers to host DECnet database... Host DECnet database successfully restored 3.6 Restoring with the Restore Parameter and from Your Start-Up Procedure There is another way, which can be automated, to restore your local DECnet database. Run DSVCONFIG with the RESTORE parameter: $ @DSVCONFIG RESTORE Using RESTORE bypasses the menu and lets you include this restoration in your system start-up procedures. If you want to restore servers to the DECnet database at system startup, edit your system start-up file. Then edit your start-up procedure so that it follows this sequence: 1. Starts DECnet. 2. Defines all DECnet node names. 3. Restores servers. Use the following command in the start-up file: $ @SYS$SYSROOT:[DECSERVER]DSVCONFIG RESTORE For VAXcluster nodes, a fourth step is sometimes required. For each node that has a different service circuit-ID from the rest of the nodes on the cluster, add another line to your start-up procedure: @SYS$COMMON:[DECSERVER]DSVCONFIG SET_CIRCUIT service-circuit-ID See Section 3.2.7 for a list of valid service circuit-IDs. The SET_CIRCUIT parameter is similar to the RESTORE parameter, but SET_CIRCUIT affects only the DECnet operational, rather than the permanent, database. This parameter ensures the correct definitions for service circuit-IDs for each node after a cluster reboot. DSVCONFIG RESTORE and DSVCONFIG SET_CIRCUIT also turn on all the specified service circuits. 3.7 Configuring on VAXcluster Nodes For VAXcluster nodes as load hosts, you must keep up to date each node's databases. The procedure you should follow depends on whether you are running for the first time the version of DSVCONFIG in your DECserver 200 software distribution kit. 3.7.1 Running DSVCONFIG for the First Time Older versions of DSVCONFIG place DSVCONFIG.DAT in the SYS$SPECIFIC directory. When you run the version of DSVCONFIG in your DECserver software distribution kit for the first time, follow this procedure to ensure that DSVCONFIG updates the DSVCONFIG.DAT file correctly and places it in the SYS$COMMON directory: 1. Run DSVCONFIG at one node to add servers. DSVCONFIG looks for the original DSVCONFIG.DAT file in the SYS$SPECIFIC directory. After finding an existing DSVCONFIG.DAT file, DSVCONFIG copies the server entries from that data file into the DSVCONFIG.DAT file on SYS$COMMON:[DECSERVER], ignoring any servers with names already existing in the SYS$COMMON file. The procedure looks at each entry in SYS$SPECIFIC and determines if that entry is already in SYS$COMMON. If the entry is in SYS$COMMON, it is not merged. If the entry is not in SYS$COMMON, it is merged. Then, DSVCONFIG renames the old DSVCONFIG.DAT file on the SYS$SPECIFIC directory to DSVCONFIG_SPECIFIC.DAT. As a result, you still have the original entries in case you need to repeat the merge. 2. At every other node, run DSVCONFIG and select the List option. DSVCONFIG merges all the existing server entries to the DSVCONFIG.DAT file in SYS$COMMON. 3. Verify that the merge was successful. The List option should display the correct service circuit-IDs at each node. Since the individual nodes have the correct service circuit-ID for each server entry, the correct IDs are merged into the new file. Informational messages display the status of the merge as it progresses. After you verify that the merge is successful, delete the DSVCONFIG_SPECIFIC.DAT file. If the service circuit-IDs are not correct for a particular node, you can correct them in one of two ways. You can run DSVCONFIG at the node with the errors (use the Swap option to change the service circuit-IDs). Or you can run DSVCONFIG SET_CIRCUIT at that node (for VAXclusters, the latter method is better). The following example shows the messages DSVCONFIG displays as it merges old server entries: $ @DSVCONFIG Merging SYS$SPECIFIC:[DECSERVER]DSVCONFIG into SYS$COMMON:[DECSERVER]DSV- CONFIG 8 servers were defined in SYS$SPECIFIC:[DECSERVER]DSVCONFIG.DAT 3 servers were already in SYS$COMMON:[DECSERVER]DSVCONFIG.DAT 5 servers merged into SYS$COMMON:[DECSERVER]DSVCONFIG.DAT You must assign a unique DECnet node name and DECnet node address for each new DECserver unit. Press to start, or to exit... 3.7.2 Running This Version of DSVCONFIG Again To establish the system as a load host immediately and make additional configuration changes for servers, run DSVCONFIG at each node and select the appropriate options. Running DSVCONFIG at each node ensures correct service circuit-IDs. Use the Restore option at each node. This option restores the server's DSVCONFIG.DAT definitions into each node's NCP database. You do not have to perform the procedure at each node if you can wait for the next reboot of the system before it can act as a load host. At reboot, the start-up procedures correct all service circuit-IDs for each node. 3.8 Exiting DSVCONFIG When you exit DSVCONFIG: 1. Give the server manager the DECserver 200 Identification Card for each server that you defined. 2. Direct the server manager to store the card in the notebook with the documentation set for DECserver 200 software. 3.9 After Exiting from DSVCONFIG After you complete the configuration procedure, verify the load host installation. See Chapter 4 for details of this procedure. 4 ____________________________________________________________ Verifying the Installation To complete the software installation, you need to perform two verifications. First, you verify the load host installation by down-line loading the server image. Then, after loading the server, you verify the server system installation. Here, system installation means the installation of the complete server system - the hardware unit with the correct software loaded and running. You verify the server system by testing a few server commands at an interactive terminal, which must be connected to the server. 4.1 Verifying the Load Host Installation To verify the installation of the load host, use it to down-line load the server image to one DECserver 200 unit; then read the DECnet event-logging messages. The messages confirm that the new load host: o Has the appropriate files in the correct directory o Has a correct entry in its node database for the server o Can successfully down-line load the server image to the server Even though there are several ways to down-line load the server image, use the NCP LOAD NODE command to verify the installation, as explained later in this section. This is the only method that tests the installation of the software from a specific load host. The LOAD NODE command lets you specify the load host, ensuring that the load host that does the down-line load is your VMS system. (A discussion of all the ways to down-line load appears in the DECserver 200 Management Guide.) You can down-line load the new server image to a new server or to an existing server that is currently operating on the network. Each situation has its own requirements, as explained below. 4.1.1 If You Are Loading a New Server A new server has no operating software in it until the initial down-line load, which occurs automatically upon server start-up. When the hardware installer powers up a unit, the server automatically requests a load of its image from any available load host. An established load host recognizes the request and down-line loads the server image. The hardware installer can then verify the hardware installation with the appropriate diagnostic lights (LEDs) on the DECserver hardware unit. However, if the server image cannot be properly down-line loaded as soon as the server is powered up, the hardware installer sees server errors. Therefore, your coordination with the server hardware installer is important. You should complete the entire software installation procedure before the hardware is powered up for the first time. Note that this automatic down-line load verifies the hardware, but it is not sufficient for verifying the load host installation. 4.1.2 If You Are Loading an Existing Server When an operating server is loaded, all sessions with service nodes are disconnected. Therefore, if an existing server is about to be loaded with a new image, your coordination with the server manager is important. Digital Equipment Corporation recommends that you talk with the server manager and the system manager about the needs of their users. It may be best to delay the verification of the installation and to down-line load during off-hours. Ask the server manager of an existing server to alert the interactive users on the server of the shutdown due to reloading. The server manager should have at least 30 minutes notice to disable connections and queuing to local services of the server if necessary. (The DECserver 200 Management Guide discusses the issues involved in shutting down the server.) 4.1.2.1 Loading During Off-Hours You and the server manager can perform the down-line load during off-hours to be least disruptive to the nodes affected by the server. To do so, you can put the LOAD command in a batch job and run it at night. 4.1.2.2 Warning Users Before Loading If you decide to reload an installed and running DECserver unit during normal working hours, either you (if you know the privileged password) or the server manager can use the server interface to issue the privileged BROADCAST ALL command to warn server users. If you wish, you can broadcast the VERIFYING THE LOAD HOST INSTALLATION warning on a remote console port. See Appendix B for information on using the Remote Console Facility (RCF) on a VMS system. Issue the BROADCAST ALL command at the server prompt (Local>). BROADCAST ALL sends a message to all the ports. The message can be up to 115 characters in length. Note that the reception of broadcasts can be disabled on ports even when it is enabled on the server. Some users, therefore, may not receive your message. However, the command also lists the ports that did not receive the broadcast message; so you can then warn these users using another method if necessary. The following command warns users at all ports that the server will be reloaded in three minutes: Local> BROADCAST ALL "The server will be reloaded in 3 minutes." 4.1.3 Down-Line Loading with the LOAD Command Down-line loading the server image for load host verification involves three steps: 1. Following the steps listed in the next section ("Preparing for the LOAD Command"). 2. Issuing the LOAD command. 3. Reading the event-logging message that reports the down-line load. 4.1.3.1 Preparing for the LOAD Command Perform the following tasks before issuing the LOAD command: 1. Check the DECnet node name or DECnet node address of the server. To execute the LOAD command, you need to know one of these node identifiers. If you do not remember this information from running the DSVCONFIG procedure (see Chapter 3), run the procedure again and select the List option from the menu. The List option displays the DECnet node name and DECnet node address of all the servers you defined in this load host's node database. 2. Ask the server manager for the server's DECnet service password if there is one (the server manager may know it as the "maintenance password"). For a previously configured server, you may need to specify this password on the LOAD NODE command line. 3. Enable DECnet event logging. Event-logging messages are generated by the Network Control Program (NCP). Enter these commands: $ MCR NCP NCP> SET LOGGING CONSOLE EVENT 0.3,7 NCP> SET LOGGING CONSOLE STATE ON NCP> SET LOGGING MONITOR STATE ON DECnet uses the Operator Communication (OPCOM) facility to display event messages on the operator's console. Make sure OPCOM is running on your host. The DCL SHOW SYSTEM command displays the status of all processes on your system. If OPCOM is not running, start it with the following command: $ @SYS$SYSTEM:STARTUP OPCOM 4. If you are reloading an existing server, warn the interactive users with the BROADCAST command. See Section 4.1.2.2 for information on issuing the BROADCAST command. Note All the other commands needed for down-line loading are part of DSVCONFIG and are executed when you run that procedure (see Chapter 3). In addition, SERVICE must be enabled on the service circuit, which is also performed by DSVCONFIG. 4.1.3.2 Issuing the LOAD Command After warning interactive users of an operating server and after enabling event logging, you are ready to load the server. Issue the LOAD NODE command at a terminal connected to your VMS load host. On the command line, enter either the DECnet node name or the DECnet node number. The following example loads an existing server named BEETHO, with a node address of 28.1002. $ MCR NCP NCP> LOAD NODE BEETHO or NCP> LOAD NODE 28.1002 If the server manager previously set a server maintenance password, you have to include the SERVICE PASSWORD keywords and specify this password as the DECnet service password on the command line, for example: NCP> LOAD NODE BEETHO SERVICE PASSWORD 0F23 To exit from NCP, type EXIT: NCP> EXIT $ 4.1.3.3 Using DECnet Event Logging After you have executed the LOAD command, check the DECnet event-logging messages that report the load to confirm that it was successful. Read the event-logging messages at your system operator's console. These messages identify your VMS system as the node that generated the event. If no errors are reported, you can assume that the down-line load was successful. You have finished verifying the new load host. See Appendix C for an example of DECnet event logging after a successful down-line load. If you do see errors on the event-logging messages, contact the server hardware installer. Check that the hardware is working satisfactorily. If it is, the problem is probably with the load host. Check your node database, especially the Ethernet address you entered when you defined the test server. Check that the server image is in the appropriate directory. Check that DECnet is running. Try the LOAD command again. Note When event logging is set up on a DECnet node, you can specify the destination (called the sink) of the messages. Digital Equipment Corporation suggests that you set up one DECnet sink node to receive all the logging events associated with down-line loading. In this way, all load request status information is available at one node. 4.2 Verifying the Server System Installation To verify the total server system installation, test a few server commands at an interactive terminal connected to a server port. This step confirms that: o The correct version of the software is in the server. o The server hardware operates with the new software. o The new software is running successfully. Follow this sequence: 1. Press the RETURN key two or more times. The following message and prompt should appear. The second line displayed ("Robin's Server") is the server's identification defined by the server manager. DECserver 200 Terminal Server Vn.n (BLnn) - LAT V5.1 Robin's Server Please type HELP if you need assistance Enter username> Note Be sure that the software version number and base-level number (BLnn) match those shown here; otherwise, you might be running old software. 2. Read the identification message to ensure that the correct version of the server image was down-line loaded. If you fail to receive this display, the problem could be: a. With the load host b. With the terminal c. That the incorrect software was down-line loaded 3. Enter your user name (any string of 1 through 16 charfacters that identifies you) and press the RETURN key. The port should now enter local mode, where the local prompt (Local>) appears: Enter username> SWINSTALLER Local> 4. Use the TEST PORT command, which verifies whether the terminal is receiving valid character data. On the command line, specify the number of lines and the number of columns you would like displayed. For example, this command displays 5 lines of 80 characters each: Local> TEST PORT COUNT 5 WIDTH 80 Note that you can interrupt this test by pressing any key. Appendix C shows an example of a TEST PORT display. 5. Issue the SHOW PORT command to display the characteristics of your port and their values: Local> SHOW PORT A port-characteristics display should appear. Appendix C shows an example of a port-characteristics display. 6. Use the SHOW SERVICES command to show what services are available to you. The following server command produces a list of services and service announcements: Local> SHOW SERVICES Appendix C shows an example of a SHOW SERVICES display. 7. Select an available service that you are authorized to use. Use the CONNECT command to verify that the server can logically connect your terminal to that service. On the command line, specify the service name to which you want to connect. The following example connects your terminal to a VMS system, named SYSTEM: Local> CONNECT SYSTEM When the server successfully connects your terminal to the service you specified, you no longer see the local prompt; rather, you are communicating with the service, in this example, your own VMS system. 8. Enter several commands to verify the ability of the server to exchange data with the service. For example, in this case, you could enter LOGIN, SHOW TIME, and SHOW USERS. 9. Press the BREAK key or log out from the service to return to local mode. Note that pressing the BREAK key does not end the service session you started. 10. Log out the terminal from the server: Local> LOGOUT If the server system verification encounters any problem, see the server manager. If you complete the above steps successfully, the test server is operating correctly, and you can report the successful load host installation and server system installation to the server manager. If this installation is a software upgrade, either you or the server manager must now reload all existing servers. A _____________________________________________________________ DECserver 200 Distribution Files These are the DECserver 200 distribution files: _____________________________________________________________ File Name Description _____________________________________________________________ KITINSTAL.COM Command file used by VMSINSTAL for part of the installation proce- dure. This file is temporary; it is not left on the system after the installation completes. DSVCONFIG.COM Configuration procedure. DSVCONFIG.DAT Data file used by DSVCONFIG.COM. DS2_nnn_ DEFAULTS.COM Command file used by the Terminal Server Manager. DS2$IVP.COM Command file used for the automated Installation Verification Procedure. DS2nnn.RELEASE_NOTES Release notes. (nnn=version number) PR0801ENG.SYS DECserver 200 software image. TSM$DS2_nnn_ADD_LOCAL_SERVICE.COM Adds a local service to a designated server/port. TSM$DS2_nnn_CTS_RTS_PRINTER.COM Sets up a printer with CTS/RTS flow control. TSM$DS2_nnn_DEDIC_SERV_PRINTER.COM Sets up a printer with a dedicated service. TSM$DS2_nnn_DEDIC_SERV_TERM.COM Sets up a terminal with a dedicated service. ____________________________________________________________ ____________________________________________________________ File Name Description ____________________________________________________________ TSM$DS2_nnn_DIAL_IN_MODEM.COM Sets up a port for attachment of a dial-in modem. TSM$DS2_nnn_DIAL_IN_OUT_MODEM.COM Sets up a dynamic access port for attachment of a dial-in/dial-out modem. TSM$DS2_nnn_DIAL_OUT_MODEM.COM Sets up a port for attachment of a dial-out modem. TSM$DS2_nnn_DSR_DTR_TERM.COM Sets up a printer with DSR/DTR flow control. TSM$DS2_nnn_GET_CHAR.COM Command file of DCL procedures. TSM$DS2_nnn_HOST_INIT_PRINTER.COM Sets up a printer and service for it. TSM$DS2_nnn_NON_LAT_HOST.COM Sets up a non-LAT host. TSM$DS2_nnn_PC_TERM_OR_SERV.COM Sets up a personal computer used as a terminal and service. TSM$DS2_nnn_PORT_DEFAULT.COM Resets port characteristics to de- fault settings. TSM$DS2_nnn_TERM_SWITCH.COM Sets up a port for use as a terminal switch. ____________________________________________________________ B ____________________________________________________________ Using the Remote Console Facility The DECserver 200 unit supports the VMS Remote Console Facility (RCF). This appendix explains how to use RCF from a VMS host. If you issue the BROADCAST command yourself to warn users of an upcoming down-line load, you may want to use RCF. To connect to the server with RCF, use the CONNECT NODE command. On the command line, specify either the DECnet node name or DECnet node address of the server. This example shows a connection to the server named BEETHO: $ MCR NCP NCP> CONNECT NODE BEETHO Console connected (press CTRL/D when finished) or NCP> CONNECT NODE 28.1002 SERVICE PASSWORD 0F23 Console connected (press CTRL/D when finished) Press the RETURN key to start the log-in sequence for the remote console. Log-in password protection is enabled for the the DECserver 200 remote console port. Therefore, you must supply the log-in password when the server prompts you with a pound sign (#), as shown below (an audible beep signal accompanies the prompt). The default password is ACCESS. # The prompt indicates that the link to the server has been made. After you enter the correct password, you can begin using DECserver 200 commands. You can also use the CONNECT command with the server's Ethernet address. The following example shows a connection from a VMS system with the service circuit-ID UNA-0 to a server with the Ethernet address 08-00-2B-04-AA-2B: NCP> CONNECT VIA UNA-0 PHYSICAL ADD 08-00-2B-04-AA-2B You may have to specify the service password with the CONNECT command if a maintenance password is specified on the server. To do so, include the SERVICE PASSWORD keywords on your command line and specify the password. To exit from RCF, type: CTRL/D: Local> CTRL/D To exit from NCP, type EXIT: NCP> EXIT $ Note If you log out from the server with a LOGOUT command, the port is logged out but the remote console session remains active. Type to exit the remote console session. The service node prompt reappears, and control passes back to NCP on your VMS system. See the DECserver 200 Management Guide for detailed information on RCF. C ____________________________________________________________ Examples: Installation, Configuration, Verification This appendix shows examples of the installation and the configuration procedures. It also shows the verification of a load host installation by down-line loading and reading DECnet event-logging messages. Finally, Appendix C shows the verification of a server system installation by testing server commands. C.1 Example of an Installation The following example shows a successful installation procedure onto a VMS V5.0 system. (In this example, server software version numbers are not supplied.) This example assumes a type of distribution media that requires only one medium, for example, a magnetic tape. For types such as TU58 cartridges, which require more than one volume, additional prompts during the procedure instruct you to mount the additional volumes. This example also shows the procedure as Digital Equipment Corporation suggests you run it: 1. Use the option that prints the release notes. 2. Print the release notes. 3. Stop the procedure to read them. 4. Rerun the procedure. $ SET DEFAULT SYS$UPDATE $ @VMSINSTAL DS2 MTA2 OPTIONS N VAX/VMS Software Product Installation Procedure V5.0 It is 17-JAN-1989 at 14:08. Enter a question mark (?) at any time for help. %VMSINSTAL-W-DECNET, Your DECnet network is up and running. * Do you want to continue anyway [NO]? Y * Are you satisfied with the backup of your system disk [YES]? Please mount the first volume of the set on MTA2:. * Are you ready? Y %MOUNT-I-MOUNTED, DS2 mounted on MTA2: The following products will be processed: DS2 Vn.n Beginning installation of DS2 Vn.n at 14:08 %VMSINSTAL-I-RESTORE, Restoring product saveset A... Release Notes Options: 1. Display Release Notes 2. Print Release Notes 3. Both 1 and 2 4. Copy Release Notes to SYS$HELP 5. Do not display, print, Or copy Release Notes * Select option [3]: 2 * Queue name [SYS$PRINT]: Job DS2nnn.RELEASE NOTES (queue SYS$PRINT, entry 314) started on SYS$PRINT * Do you want to continue the installation [N]? VMSINSTAL procedure done at 14:09 $ Read the release notes. Run VMSINSTAL again: $ @VMSINSTAL DS2 Mua0 VAX/VMS Software Product Installation Procedure V5.1 It is 14-MAR-1989 at 14:07. Enter a question mark (?) at any time for help. %VMSINSTAL-W-DECNET, Your DECnet network is up and running. * Do you want to continue anyway [NO]? yes * Are you satisfied with the backup of your system disk [YES]? Please mount the first volume of the set on MUA0:. * Are you ready? yes %MOUNT-I-MOUNTED, DS2 mounted on _MUA0: The following products will be processed: DS2 Vn.n Beginning installation of DS2 Vn.n at 14:09 %VMSINSTAL-I-RESTORE, Restoring product saveset A... %VMSINSTAL-I-RELMOVED, The product's release notes have been successfully moved to SYS$HELP. * Do you want to run the IVP after the installation [YES]? %VMSINSTAL-I-RESTORE, Restoring product saveset B... Your installation is now complete. After exiting from VMSINSTAL: 1. Edit your system start-up file so that it defines the logical MOM$LOAD as a search string with a value equal to itself, plus the added element SYS$SYSROOT:[DECSERVER]. For example: DEFINE/SYSTEM/EXEC/NAME ATTRIBUTE=NO_ALIAS/NOLOG - MOM$LOAD 'current-search-string',SYS$SYSROOT:[DECSERVER] If the current search string associated with MOM$LOAD in your start-up file is SYS$SYSROOT:[DECSERVER] or if you have already made this change for a previous installation, there is no need to edit this file. This command ensures that the location of the server image is defined each time the system is rebooted, necessary for successful down-line loading. 2. Configure the server into your host's database. Execute a command procedure called DSVCONFIG.COM. This command procedure is in the SYS$SYSROOT:[DECSERVER] directory. If you have already executed this procedure from previous installations, you need to configure only any additional units. All previously defined units will still be configured. 3. The Installation Verification Procedure (IVP) for the DECserver 200 can be found in SYS$TEST and may be run at any time by executing the command procedure DS2$IVP. %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories Beginning installation verification procedure for DECserver 200 Vn.n. Successfully located SYS$SYSROOT:[DECSERVER] directory Successfully located SYS$SYSROOT:[DECSERVER]DS2nnn.RELEASE_NOTES Successfully located SYS$SYSROOT:[DECSERVER]PR0801ENG.SYS Successfully located SYS$SYSROOT:[DECSERVER]DSVCONFIG.COM Successfully located SYS$SYSROOT:[DECSERVER]DSVCONFIG.DAT Successfully located SYS$SYSROOT:[DECSERVER]DS2_nnn_DEFAULTS.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_ADD_LOCAL_ SERVICE.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_CTS_RTS_ PRINTER.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DEDIC_SERV_ PRINTER.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DEDIC_SERV_ TERM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DIAL_IN_ MODEM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DIAL_IN_OUT_ MODEM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DIAL_OUT_ MODEM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_DSR_DTR_ TERM.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_GET_CHAR.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_HOST_INIT_ PRINTER.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_NON_LAT_ HOST.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_PC_TERM_ OR_SERV.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_PORT_ DEFAULT.COM Successfully located SYS$SYSROOT:[DECSERVER]TSM$DS2_nnn_TERM_ SWITCH.COM Depending on your system, VMSINSTAL might let you make an entry in the Software History log. The procedure concludes: VMSINSTAL procedure done at 14:28 $ C.2 Example of a Configuration This section gives examples of the following: o Starting DSVCONFIG o Listing known terminal servers (Option 1) o Adding a terminal server (Option 2) o Swapping an old terminal server for a new terminal server (Option 3) o Deleting a terminal server from the database (Option 4) o Restoring existing terminal servers to the database (Option 5) C.2.1 Starting DSVCONFIG.COM The following example shows the beginning of the configuration procedure. This example assumes that the latest version of DSVCONFIG has already been run so that the DSVCONFIG.DAT file exists in the correct format. (See Chapter 3 for the prompts that are displayed if the procedure has to either create DSVCONFIG.DAT or reformat it.) $ SET DEFAULT MOM$LOAD $ @DSVCONFIG You must assign a unique DECnet node name and DECnet node address for each DECserver you are going to configure. Press to start, or to exit... DECserver Configuration Procedure Version: Vn.n Menu of Options 1 - List known DECservers 2 - Add a DECserver 3 - Swap an existing DECserver 4 - Delete an existing DECserver 5 - Restore existing DECservers CTRL/Z - Exit from this procedure Your selection? C.2.2 Listing Known Terminal Servers (Option 1) This section and the following ones show how the configuration procedure continues for each option. With the exception of List, each option ends by automatically returning you to the menu. Your selection? 1 DECnet DECnet Server Service Address Name Type Circuit Ethernet Address Load File Dump File ------- ------ ------ ------ ----------------- ------------- ------------- 28.1001 BACH DS200 UNA-0 08-00-2B-02-24-CC PR0801ENG.SYS DS2BACH.DMP 28.1003 MOZART DS100 UNA-0 08-00-2B-02-24-DD PS0801ENG.SYS PSDMP24DD.SYS 28.1005 HAYDN DS200 UNA-1 08-00-2B-03-AA-F1 PR0801ENG.SYS DS2HAYDN.DMP Total of 3 DECservers defined. C.2.3 Adding a Terminal Server (Option 2) This example adds a new DECserver 200 unit named BEETHO. Your selection? 2 Type a ? at any time for help on a question. Type CTRL/Z for any question to return to the menu without adding the unit. DECserver type? DS200 DECnet node name for unit? BEETHO DECnet node address for unit? 28.1002 Ethernet address of unit? 08-00-2B-03-AA-2B DECnet Service Circuit-ID? [UNA-0] If you get an error message now, the new unit won't be added, and you should delete it from the directory. If you use the List option to get a listing of servers, you see that BEETHO appears on the listing of entries. C.2.4 Swapping an Old Unit for a New Unit (Option 3) In this example, an existing DECserver 100 unit named MOZART is swapped for a new DECserver 200 unit, which is given the same DECnet node name. The DECnet node address always stays the same with Swap. The new server also has the same service circuit-ID as the old server. (If you use Swap to change the characteristics of the same server, you have to specify the Ethernet address even though it will not change.) Your selection? 3 Type a ? at any time for help on a question. Type CTRL/Z for any question to return to the menu without changing the unit. What is the DECnet node name you want to swap? MOZART DECserver at Ethernet address 08-00-2B-02-24-DD is being modified. Enter the new Ethernet address, and any other DECnet characteristics you want to modify. DECserver type? [DS100] DS200 DECnet node name for unit? [MOZART] Ethernet address of unit? 08-00-2B-03-AA-AB DECnet Service Circuit-ID? [UNA-0] C.2.5 Deleting a Terminal Server from the Database (Option 4) This example shows the deletion from the load host's node database of the existing server with the DECnet node name BACH. Your selection? 4 (Press CTRL/Z to return to menu.) Enter the DECnet node name of the server you want to delete? BACH %NCP-I-NMLRSP, listener response - Success Remote node = 28.1001 (BACH) %NCP-I-RECDELET, Database entry deleted If you use the List option to get a listing of servers, you see that BACH no longer appears. C.2.6 Restoring Existing Terminal Servers to the Database (Option 5) This example shows the restoration of the local down-line load database. Your selection? 5 Restoring existing DECservers to host DECnet database... Host DECnet database successfully restored. C.3 Example of Verification: Verifying a Load Host Installation The following example, presented in five parts, shows the installation verification for a VMS load host. This procedure tests that your VMS system can perform successfully as a down-line load host for a particular server. In this example, the VMS system is named SYSTEM. The server that is loaded is a DECserver 200 unit with DECnet node name BEETHO. BEETHO is an existing server currently operating on the network. This example assumes that the down-line load is performed during normal working hours and that server users are warned of the upcoming down-line load by way of RCF. C.3.1 Using RCF and Warning Server Users This example uses the server's default log-in password, ACCESS. $ MCR NCP CONNECT NODE BEETHO SERVICE PASSWORD FF23 Console connected (press CTRL/D when finished) # ACCESS (not echoed) DECserver 200 Terminal Server V3.0 (BL33) - LAT V5.1 Please type HELP if you need assistance Enter username> SWINSTALLER Local>SET PRIVILEGED Password> password (not echoed) Local> BROADCAST ALL "The server will be reloaded in 3 minutes." Local> $ C.3.2 Enabling DECnet Event Logging and Checking Server Names NCP> SET LOGGING CONSOLE EVENT 0.3,7 NCP> SET LOGGING CONSOLE STATE ON NCP> SET LOGGING MONITOR STATE ON NCP> EXIT $ SET DEFAULT MOM$LOAD $ @DSVCONFIG You must assign a unique DECnet node name and DECnet node address for each DECserver you are going to configure. Press to start, or to exit... DECserver Configuration Procedure Version: Vn.n Menu of Options 1 - List known DECservers 2 - Add a DECserver 3 - Swap an existing DECserver 4 - Delete an existing DECserver 5 - Restore existing DECservers CTRL/Z - Exit from this procedure Your selection? 1 DECnet DECnet Server Service Address Name Type Circuit Ethernet Address Load File Dump File ------- ------ ------ ------- ----------------- ------------- ------------- 28.1002 BEETHO DS200 UNA-0 08-00-2B-03-AA-2B PR0801ENG.SYS DS2BEETHO.DMP Total of 1 DECserver defined. DECserver Configuration Procedure Version: Vn.n Menu of Options 1 - List known DECservers 2 - Add a DECserver 3 - Swap an existing DECserver 4 - Delete an existing DECserver 5 - Restore existing DECservers CTRL/Z - Exit from this procedure Your selection? $ C.3.3 Down-Line Loading with the LOAD Command $ MCR NCP LOAD NODE BEETHO PASSWORD FF23 C.3.4 DECnet Event-Logging Display After Issuing LOAD NCP> LOAD NODE BEETHO SERVICE PASSWORD FF23 DECnet event 0.3, automatic line service From node 4.205 (SYSTEM), 18-JAN-1989 01:35:20.47 Circuit UNA-0, Load, Requested, Node = 28.1002 (BEETHO) File = MOM$LOAD:PR0801ENG, Operating system Ethernet address = 08-00-2B-03-AA-2B DECnet event 0.3, automatic line service From node 4.205 (SYSTEM), 18-JAN-1989 01:43:21.14 Circuit UNA-0, Load, Successful, Node = 28.1002 (BEETHO) File = MOM$LOAD:PR0801ENG, Operating system Ethernet address = 08-00-2B-04-AA-2B C.3.5 Checking the Service Circuit This part is optional, and is presented in case the service circuit becomes disabled. Type the following command to verify that the service circuit, BNA-0, is enabled: NCP>SHOW CIR BNA-0 CHARACTERISTICS Circuit Volatile Characterisitics as of 17-Jun-89 08:23:45 Circuit = BNA-0 State =on Service =disabled Designated router = 4.378 (LKGRT3) Cost =4 Router priority =64 Hello timer =15 Type =Ethernet Adjacent node = 4.378 (LKGRT3) Listen timer =90 If the state is disabled, first check that the system is not busy by typing the following command: NCP>SHOW KNOWN LINKS Known Link Volatile Summary as of 17-Jun-89 08:25:23 Link Node PID Process Remote Link Remote User 33848 2.119 (DSSDEV) 24203120 MCGREGOR 34655 MAIL 8615 3.264 (RITA) 2420372C POOR 309 CTERM 34154 4.10 (SMAUG) 24203F2B MAIL_34154 33388 DECNET_MAIL NCP> The example shows that there are three users. If you enable the circuit at this time, you will disable the current users. If the circuit is not busy, type the following commands to enable the service circuit, BNA-0. NCP>SET CIR BNA-0 STATE OFF NCP>SET CIR BNA-0 SERVICE ENABLED STATE ON C.3.6 Conclusion of a Load Host Installation Verification NCP> CLEAR LOGGING CONSOLE EVENT 0.3,7 NCP> EXIT $ C.4 Example of Verification: Verifying the Server System Installation This example shows the verification of a server system installation. This procedure tests the hardware, the correctness of the software version, and the ability of the new software to run successfully. It assumes that you are at a terminal connected to the server's Port 1, that your user name is SWINSTALLER, that your user password is SQUIDS, that you will test the server by connecting to your own VMS system, SYSTEM, and that the new DECserver 200 software is Version 3.0. DECserver 200 Terminal Server V3.0 (BL33) - LAT V5.1 Please type HELP if you need assistance Enter username> SWINSTALLER Local> TEST PORT COUNT 5 WIDTH 65 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^ ` !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^ `a "#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^ `ab #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^ `abc $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^ `abcd Local> SHOW PORT The display at the port of a new DECserver 200 unit should match the following example, which contains the factory-set values, except for the port number and user name: Port 1: SWINSTALLER Character Size: 8 Input Speed: 9600 Flow control: XON Output Speed: 9600 Parity: None Modem Control: Disabled Access: Local Local Switch: None Backward Switch: None Name: PORT 1 Break: Local Session Limit: 4 Forward Switch: None Type: Soft Preferred Service: None Authorized Groups: 0 (Current) Groups: 0 Enabled Characteristics: Autobaud, Autoprompt, Broadcast, Input Flow Control, Loss Notification, Message Codes, Output Flow Control, Verification Local> SHOW SERVICES ALL SUMMARY Service Name Status Identification ----------- ------ -------------- DEVELOP 2 Connected Hardware Timesharing Service Ident DOCUMENT Available Documentation Timesharing TEST Unavailable As usual TIMESHARING Unknown Server Software Development SYSTEM Available VAX/VMS 8600 Local> CONNECT SYSTEM Local -010- Session 1 to SYSTEM established SYSTEM -- VAX 8600, The Best for Down-line Loading Username: SWINSTALLER Password: SQUIDS (not echoed) Welcome to VAX/VMS version V5.0 on node SYSTEM Last interactive login on Wednesday, 17-JAN-1989 07:25 Last non-interactive login on Thursday, 27-DEC-1988 17:18 SYS$MANAGER:NOTICE.TXT -- SYSTEM System Notices ------------------------------------------------------------------- ------------------------------------------------------------------- 18-Jan-1989 All users, please purge your files! $ SHOW TIME 18-JAN-1989 07:00:09 $ SHOW USERS VAX/VMS Interactive Users 18-JAN-1989 07:00:13.13 Total number of interactive users = 4 Username Process Name PID Terminal ----------------------------------------------------------------- DAISY DAISY 20A0257A VTA3341 LTA3341: HEATHER HEATHER 20A02217 VTA3391 LTA3391: IVY IVY 20A020D2 VTA3234 Disconnected ROSE ROSE 20A02321 VTA3471 LTA3471: SWINSTALLER SWINSTALLER 20A02001 VTA3471 LTA3511: $ LOGOUT SWINSTALLER logged out at 18-JAN-1989 07:00:20.98 Local -011- Session 1 disconnected from SYSTEM Local> LOGOUT Local -020- Logged out port 1 D __________________________________________________ How to Report a Problem If you discover a problem with the operation of the DECserver 200 terminal server software, check to see if the problem is already known before submitting an SPR. If it is, workarounds or corrections may already be available, which will minimize any disruption caused by the problem. To check this, perform the troubleshooting procedures outlined in the DECserver 200 Problem Determination Guide and verify the source of the problem. Also, read Sections 5 and 6 of the Release Notes, which describe known restrictions and problems with this release. If the software is still under warranty, or if you purchased Digital Equipment Corporation support services, call the telephone hot line to report your problem. They may be able to provide you with information and workarounds to solve the problem immediately. D.1 Submitting an SPR When completing a Software Performance Report (SPR), describe one problem at a time. This simplifies record keeping and facilitates a quick response. Keep the description simple yet accurate. Illustrate a general problem with several examples. If a FATAL BUGCHECK error occurs, message number nnnnn, submit a crash dump. See Chapter 8 of the DECserver 200 Problem Determination Guide for more details. Because problems are often difficult to reproduce with different system configurations, please include as much detail as possible when reporting a problem. Define as precisely as possible the state of your system when the problem occurred, and indicate the sequence of events or commands that caused the problem. Attempt to reproduce the situation, if it can be reproduced, using the minimum number of steps. If one of your user programs causes a problem in the DECserver 200 terminal server, and you are unable to send the program to Digital, try to reproduce the problem with a standard utility. If this is not possible, try to describe the program's operation before and after the suspected failure. When an SPR contains concise information about a problem, we are more likely to be able to reproduce and correct the problem. Please ensure that any questions are direct and simply stated so they can be answered clearly and directly. D.2 Reporting Documentation Problems When describing a problem found in a manual, specify the full title of the manual and identify the appropriate section, figure, table, or page number. Describe what the manual says and also describe any of the suggested corrections. You can use the Reader's Comments Card in the back of the manual. If you are reporting an error with on-line HELP, identify the full command and screen, and specify TUTORIAL or REFERENCE HELP. D.3 Handling Severe Errors Severe errors may cause your DECserver 200 terminal server to hang or bugcheck. Server hangs are usually recovered after 20 seconds by an automatic power fail, followed by a down-line load. If this sequence occurs, please describe as best you can the operating conditions on the server at the time of the hang. If a FATAL BUGCHECK occurs, a bugcheck message (message nnnnn) is printed out on the console terminal, showing the vital registers at the time of the bugcheck. Normally, an up-line crash dump is automatically created upon a fatal bug check error. For other types of problems a crash dump is also an extremely valuable tool: if you experience a problem that is not easily reproducible, a crash dump normally allows Digital to fix the problem even if it is not reproducible. You can force a crash by typing `CRASH' at the Local>prompt in privileged local mode. A code 300 fatal bug check will occur immediately. The location of the crash dump file may be determined as follows: 1. After the server reinitializes, enter privileged local mode and issue a SHOW SERVER STATUS command. Information in this display indicates the Ethernet address of the dump host. You can identify the dump host from this address. 2. The crash dump will be located in the directory SYS_$COMMON:[DECSERVER] on the dump host, and the file name will be DS2xxxxxx.DMP. Here, xxxxxx is the DECnet node name assigned to the server unit, as defined using the DSVCONFIG configuration procedure. For example, if the DECserver 200 with node name LAT041 bugchecks, the crash dump will be found in SYS_$COMMON:[DECSERVER]- DS2LAT041.DMP on the dump host. Copy the crash dump file to magtape (preferred), RX50, TK50, RX01 or TU58 media. Indicate on a label the format of the copy (COPY, BACKUP, FLX, etc.). All media sent to Digital Equipment Corporation will be returned to the sender.