MUXserver 300 Software Installation Guide (VMS) Order Number AA-MJ87C-TE Digital Equipment Corporation (Australia) Pty. Limited ________________________ Third Edition, October 1990 __________ The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation (Australia) Pty. Limited. Digital Equipment Corporation (Australia) Pty. Limitedassumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation (Australia) Pty. Limited or its affiliated companies. __________ Copyright ©1990 by Digital Equipment Corporation (Australia) Pty. Limited. All Rights Reserved. Printed in Australia. __________ The postpaid READER'S COMMENTS form on the last page of this document requests the user's critical evaluation to assist in preparing future documentation. The following are trademarks of Digital Equipment Corpora- tion: DEC DIBOL UNIBUS DEC/CMS EduSystem UWS DEC/MMS IAS VAX DECnet MASSBUS VAXcluster DECstation PDP VMS DECsystem-10 PDT VT DECSYSTEM-20 RSTS DECUS RSX DECwriter ULTRIX DIGITAL This document was prepared using VAX DOCUMENT, Version 1.2 Contents________________________________________________________ Preface_______________________________________________________vi Chapter_1__Introduction_to_the_MUXserver/DECmux_300_____________ 1.1 Introduction..........................................1-1 1.1.1 What is the MUXserver 300?..................1-1 1.1.2 Overview of Software Installation...........1-1 1.2 MUXserver/DECmux 300 Concepts.........................1-1 1.2.1 Connections.................................1-2 1.2.2 Services....................................1-2 1.2.3 Service Nodes and LAT Protocol..............1-2 1.2.4 LAT Software................................1-3 1.3 Performing the Software Installation..................1-3 1.3.1 Introduction................................1-3 1.3.2 Installing the MUXserver 300 Distribution Software....................................1-5 1.3.3 Configuring the Load Host's Node Database....................................1-5 1.4 Verifying the Installation............................1-7 1.4.1 Verifying the Load Host Installation........1-7 1.4.2 Verifying the Server System Installation....1-8 Chapter_2__Installing_Distribution_Software_____________________ 2.1 Introduction..........................................2-1 2.2 Preparing to Run the Installation Procedure...........2-1 2.3 Software Prerequisites................................2-2 2.3.1 VMS Tailoring...............................2-2 2.4 VMSINSTAL Conventions.................................2-2 iii 2.5 Running VMSINSTAL.....................................2-2 2.5.1 Running VMSINSTAL on VMS V4.6 and Later.....2-3 2.6 Installing onto Alternate Load Hosts..................2-7 2.6.1 Installing onto Single Systems..............2-8 2.6.2 Installing onto VAXclusters.................2-8 2.6.3 Installing onto Other Operating Systems.....2-8 2.7 Installation Verification Procedure...................2-9 Chapter_3__Configuring_the_Load_Host's_Node_Database____________ 3.1 Introduction..........................................3-1 3.2 Preparing to Run the Configuration Procedure..........3-4 3.3 DSVCONFIG Conventions and Requirements................3-5 3.4 Running DSVCONFIG.....................................3-5 3.4.1 List Known Servers (Option 1)...............3-8 3.4.2 Add a Server (Option 2).....................3-9 3.4.3 Swap an Existing Server (Option 3).........3-11 3.4.4 Delete an Existing MUXserver (Option 4)....3-13 3.4.5 Restore Existing MUXservers (Option 5).....3-13 3.4.6 Restoring from a Command Procedure.........3-14 3.5 Down-Line Loading the Server Image...................3-14 Chapter_4__Verifying_the_Installation___________________________ 4.1 Introduction..........................................4-1 4.2 Verifying the Load Host Installation..................4-2 4.2.1 Loading a New Server........................4-2 4.2.2 Loading an Existing Server..................4-3 4.2.3 Loading After Hours.........................4-3 4.2.4 Warning Users before Loading................4-4 iv 4.2.5 Down-Line Loading with the LOAD Command.....4-4 4.2.5.1 Preparing for the LOAD Command........4-5 4.2.5.2 Issuing the LOAD Command..............4-6 4.2.6 Using DECnet Event Logging..................4-6 4.3 Verifying the Server System Installation..............4-7 Appendix_A__MUXserver_300_Distribution_Files____________________ Appendix_B__Using_the_Remote_Console_Facility___________________ Appendix_C__Installation,_Configuration_&_Verification_Examples_ C.1 Introduction..........................................C-1 C.2 Example of an Installation............................C-1 C.3 Configuration Examples................................C-4 C.3.1 Starting DSVCONFIG.COM......................C-5 C.3.2 The DSVCONFIG.COM Menu......................C-5 C.3.3 Listing Known Servers (Option 1)............C-6 C.3.4 Adding a Server (Option 2)..................C-6 C.3.5 Swapping a MUXserver 300 for a New Unit (Option 3)..........................................C-7 C.3.6 Deleting a Server from the Database (Option 4)..........................................C-7 C.3.7 Restoring Existing Servers to the Database (Option 5)..................................C-8 C.4 Verification Examples.................................C-8 C.4.1 Verifying a Load Host Installation..........C-8 C.4.2 Using RCF and Warning Server Users..........C-8 C.4.3 Enabling DECnet Event Logging and Checking Server Names................................C-9 v C.4.4 Down-Line Loading with the LOAD Command....C-10 C.4.5 DECnet Event-Logging Display after Issuing LOAD.......................................C-10 C.4.6 Conclusion of a Load Host Installation Verification...............................C-10 C.4.7 Verifying the Server System Installation...............................C-11 Glossary________________________________________________________ Index___________________________________________________________ vi Preface_________________________________________________________ Purpose of the Manual This document describes: o Installing MUXserver 300 Remote Terminal Server distribu- tion software onto a VAX/VMS system running DECnet Phase IV so that this system can then perform as a load host. o Configuring the load host's node database. o Verifying the installation by first down-loading the server image to the MUXserver 300 Remote Terminal Server and then testing a number of server commands. This guide is applicable to Version 1.2 of the MUXserver 300 and all subsequent maintenance releases up to the next major product release. This Guide is intended for system or network managers who are responsible for making server products available on their Ethernet(s). A system manager is responsible for the VAX/VMS system that is about to be established as a load host. A network manager is responsible for the Local Area Network (LAN). Readers should be familiar with both DECnet Phase IV Network Management Concepts and the VAX/VMS Operating System. vi The Guide is organized as follows: Chapter Introduces the MUXserver/DECmux 300 Network and 1 summarizes the installation, configuration, and verification procedures. Chapter Describes preparation for installation and the 2 actual installation of distribution software. Chapter Describes configuration of the load host's node 3 database. Chapter Describes verification of the installation. 4 Appendix Lists the files provided in the MUXserver 300 A Distribution Kit. Appendix Describes the VMS Remote Console Facility (RCF). B Appendix Contains examples of the installation and configu- C ration procedures and examples of verification by down-loading. Glossary Defines all abbreviations and special terms used in this guide. Index Provides a page reference to all important topics used in this guide. Other MUXserver/DECmux 300 Publications The following is a list of related MUXserver/DECmux 300 publications: o MUXserver/DECmux 300 Network Reference Manual EK-DSRZC-RM Describes procedures for setting-up, managing, monitoring, and troubleshooting the MUXserver/DECmux 300 network. vii o MUXserver/DECmux 300 User's Guide EK-DSRZC-UG Summarizes the terminal user's environment and non- privileged commands. o MUXserver/DECmux 300 Network Installation Manual EK-DSRZC- IM Describes installation and maintenance of the MUXserver /DECmux 300 hardware. o MUXserver/DECmux 300 Network Identification Card EK-DSRZC- ID A means of recording MUXserver/DECmux 300 identification information. o DECmux 300 Technical Manual EK-DSRZC-TD Describes the technical and operational features of the DECmux 300 Remote Terminal Multiplexer. o MUXserver 300 Technical Manual EK-DSRZC-TM Describes the technical and operational features of the MUXserver 300 Remote Terminal Server. o MUXserver 300 Software Product Description Describes the MUXserver/DECmux 300's software and its operation. o MUXserver 300 System Support Addendum An addendum to the MUXserver 300 Software Product Description which describes the various systems supported by the MUXserver/DECmux 300. Other Relevant Publications Reference to the following Digital publications may be required during installation of the MUXserver/DECmux 300 software: o VAX/VMS Networking Manual Explains DECnet-VAX and VAX-PSI network software and describes network configuration, management and operation. viii o VAX/VMS Network Control Program Reference Manual Describes DECnet event logging and NCP and DECnet commands. o VAX/VMS System Messages and Recovery Procedures Reference Manual Describes NCP information and error messages. ix Conventions Throughout this guide, the following conventions apply: Product Name o Unless stated otherwise, MUXserver 300 refers to MUXserver 300 and MUXserver 310. Numbers o All numbers are in decimal unless otherwise noted. o All Ethernet addresses are in hexadecimal. Graphics Normal Normal type indicates an example of system output. Bold Bold type indicates an example of user input. Italics Indicates a variable. Indicates a specific key to be pressed. Indicates that the key should be held down while the key, specified by x, is also pressed. [ ] In a command line, indicates that the enclosed values are optional. Do not type the brackets. { } In a command line, indicates that you must specify one (and only one) of the enclosed values. Do not type the braces. / Indicates related alternative commands or options. For example, SET/DEFINE PORT refers to the SET PORT and/or DEFINE PORT commands. x Chapter__1______________________________________________________ Introduction to the MUXserver/DECmux 300 1.1 Introduction 1.1.1 What is the MUXserver 300? The MUXserver 300 is a remote terminal server that connects remote terminals (or other asynchronous port devices) to an Ethernet Local Area Network (LAN), via DECmux 300s, allowing each device to communicate with other LAT nodes on that LAN. The MUXserver 300 connects up to 48 active devices and the MUXserver 310 connects up to 16 active devices. An active terminal is one that is using a LAT service or is currently at the Local> or Enter Username> prompt. 1.1.2 Overview of Software Installation The software that you are about to install is comprised of the files in the MUXserver 300 Distribution Kit. After you install the distribution software configure the load host's node database for all new servers. Next, verify the installation by down-line loading one test server. Issue a few server commands to test the server system. 1.2 MUXserver/DECmux 300 Concepts The MUXserver 300 is used in conjunction with one or more DECmux 300 Remote Terminal Multiplexers. The MUXserver/DECmux 300 network gives terminals access to all services offered by the LAN to which the MUXserver 300 is connected. Introduction to the MUXserver/DECmux 300 1-1 1.2.1 Connections Port devices may be connected directly to the network's DECmux 300 remote units or connected remotely by means of modems. The DECmux 300 also supports printers and connections to hosts that support EIA-232-D asynchronous connections. Terminals and printers may be connected to DECmux 300 remote units with DECconnect cables. 1.2.2 Services The MUXserver/DECmux 300 gives terminals access to services offered on the LAN. A service is a resource, such as a computer. Each MUXserver/DECmux 300 user can have up to eight simultaneous connections to these various services. However, they can actively use only one connection at a time. 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 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 VAX/VMS Operating Systems to function as LAT service nodes. The MUXserver/DECmux 300 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 Introduction to the MUXserver/DECmux 300 1.2.4 LAT Software LAT is implemented on a VMS node by software included in the VMS Operating System. This includes 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 LTDRIVER. LATCP can be used to start and stop the driver as well as to set and to display characteristics of the driver. 1.3 Performing the Software Installation 1.3.1 Introduction As software installer you have the following responsibili- ties: o Installing the MUXserver 300 distribution software. o Configuring the load host's node database. o 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. The purpose of these three activities is to establish 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. Introduction to the MUXserver/DECmux 300 1-3 A load host can be a single VMS system or 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 versions of DECnet software, refer to the Software Product Description for the MUXserver 300. Digital Equipment Corporation advises the network manager to assign: o For each server, at least two load hosts o At least one load host for every ten servers Alternate load hosts free the server from dependence on one particular load host. If the primary load host is unavailable, another system can down-line load the server and receive up-line dumps from it. Digital Equipment Corporation strongly suggests that the server have these load-host functions available at all times. In addition, assigning more than one load host for every ten servers reduces the demand on any single load host's resources. When selecting alternate load hosts you can choose any Digital system that has a MUXserver 300 Distribution Kit is available. MUXserver 300 Software Distribution Kits are available for the following systems: o VAX/VMS o ULTRIX 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, refer to the MUXserver 300 Software Installation Guide for that system. You are also responsible for the total software installation procedure which requires coordination with both the MUXserver /DECmux 300 hardware installer of a new installation and the server manager of an existing server. For example, the 1-4 Introduction to the MUXserver/DECmux 300 software should be installed on the load host before the MUXserver 300 hardware is powered-up for the first time. Chapter 4 details the necessary coordination efforts among you, the hardware installer, and the server manager. 1.3.2 Installing the MUXserver 300 Distribution Software MUXserver 300 distribution software is installed onto a VMS system using an automated procedure called VMSINSTAL. The MUXserver 300 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 MUXserver 300 release notes as an option. Refer to Chapter 2 for instructions on installing the distribution software. 1.3.3 Configuring the Load Host's Node Database Once you have installed the distribution software onto your VMS system, you must configure its node database to support new servers. You configure this database with an automated procedure called DSVCONFIG. The configuration procedure file is part of the MUXserver 300 Software Distribution Kit. This kit will only update the DSVCONFIG.COM file if the version with the kit is newer than the version currently in the system. The old version of DSVCONFIG.COM file will be renamed to DSVCONFIG.COM_Vxx, where xx is the version number of the old file. Note Installing a DECserver 100 V1.x, a DECserver 200 V1.x or, a MUXserver 100 pre-V2.2 kit will cause Introduction to the MUXserver/DECmux 300 1-5 the DSVCONFIG.COM file to be overwritten by one which does not support the MUXserver 300. Configuration of the load host's node database means defining an entry for each server in a data file called DSVCONFIG.DAT. This file is automatically created by DSVCONFIG and is part of a load host's node database. Configuration of a new server involves adding an entry to this database. The entry identifies the server type, its DECnet node name and DECnet node address, its service circuit-ID, its Ethernet address, its dump file, and the server image. Configuration can also consist of modifying or deleting entries for existing servers. With DSVCONFIG you can configure the load host's node database in the following manner: o Add a new unit o Swap an old unit with a new one o Remove a unit o Restore the previous configuration from the local database To configure a server on a VAXcluster, install the distri- bution software onto one member node and then configure the node databases of the members that you want to establish as load hosts. When you complete the configuration procedure, you have established your VMS Operating System as a load host for each server that has an entry in the node database. Refer to Chapter 3 for instructions on configuring the load host's node database to support servers. 1-6 Introduction to the MUXserver/DECmux 300 1.4 Verifying the Installation After you have configured the node database, you have established your VMS system as a load host. Your final responsibility is to verify the installation. You need to perform the following two verifications: o 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. o To verify the total server system installation, test a number of 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.4.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. Introduction to the MUXserver/DECmux 300 1-7 1.4.2 Verifying the Server System Installation Using a number of server commands at an interactive terminal attached to a server port completes your verification of the server system installation. 1-8 Introduction to the MUXserver/DECmux 300 . Introduction to the MUXserver/DECmux 300 1-9 Chapter__2______________________________________________________ Installing Distribution Software 2.1 Introduction This chapter describes preparation and installation of the MUXserver 300 distribution software onto your VMS load host. To install the software use the VMSINSTAL command which is part of the VMS operating systems. Use VMSINSTAL.COM to install the distribution software. VMSINSTAL is an automated procedure that: o Creates a directory called SYS$SYSROOT:[DECSERVER] on the load host. o Copies the files from the distribution media into this directory. o Optionally prints a copy of the release notes. 2.2 Preparing to Run the Installation Procedure Before you run the installation procedure: o Determine which systems are to be load hosts for the server. You must install the distribution software onto all load hosts. o Check that there are 1000 blocks of free disk space on each load host for down-line loading the server image. o Check that DECnet Phase IV is running and in the ON state. For information on DECnet Phase IV, see the DECnet-VAX Network Management Concepts and Procedures manual. Installing Distribution Software 2-1 2.3 Software Prerequisites One of the following two operating systems and DECnet VAX are required: o VMS Operating System V4.6 or greater o MicroVMS Operating System V4.6 or greater 2.3.1 VMS Tailoring The MUXserver 300 can be run on a tailored VMS system. Information on VMS Tailoring is contained in the System Support Addendum to the MUXserver 300 Remote Terminal Server Software Product Description. 2.4 VMSINSTAL Conventions VMSINSTAL is an interactive procedure. The procedure displays a series of questions preceded by an asterisk (*). After a question the default response, if there is one, appears in brackets ([]). At the end of the display line either a colon (:) or a question mark (?) appears. Type your response immediately after the colon or question mark followed by . To choose the default type only . If you enter a question mark (?) as a response, VMSINSTAL provides explanatory text about the question and the question is repeated. Refer to the VMS documentation for a complete description of VMSINSTAL. 2.5 Running VMSINSTAL 2-2 Installing Distribution Software 2.5.1 Running VMSINSTAL on VMS V4.6 and Later Run VMSINSTAL.COM from the system manager's account. The installation procedure takes approximately 15 minutes. To begin, place the server distribution medium on the appropriate device drive. Next, log in to the system account and enter the following commands: $SET DEFAULT SYS$UPDATE $@VMSINSTAL MS3 device-identifier OPTIONS N Here, device-identifier is the device on which the distribu- tion medium is mounted. Note Running the procedure with this command line is the only way to get the release notes printed automatically. If you run VMSINSTAL without these keywords-device-identifier OPTIONS N-the release notes will not be mentioned and you will not be asked if you would like them printed. VMSINSTAL then displays the procedure title, the data and time, and 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 Y and then press to answer YES and proceed with the installation. *Are you satisfied with the backup of your system disk [YES]? Press to answer YES, or take appropriate action. If you are installing from the distribution media (not from copied savesets), you are prompted to mount the first volume by: Please mount the first volume of the set on device-identifier. *Are you ready? Installing Distribution Software 2-3 Type and press . A confirmation message says that the medium is mounted. The procedure continues: The following products will be processed: MS3 V1.2 Beginning installation of MS3 V1.2 at 14.08 %VMSINSTAL-I-RESTORE, Restoring product saveset A... The procedure now lists the following options for printing and displaying the release notes. Digital Equipment Corporation suggests that you print the release notes. Release notes included with this kit are always copied to SYS$HELP. Additional Release Notes Options: 1. Display release notes 2. Print release notes 3. Both 1 and 2 4. None of the above * Select option [2] Select one of these options. Again, Digital recommends that you select Option 2. If you select Option 1, the following message is displayed: VMI$ROOT:[SYSUPD.MS3nnn]MS3$nnn.RELEASE_NOTES;1 The release notes will be immediately displayed on your terminal. If you select Option 2, you are asked to queue the file for printing: * Queue name [SYS$PRINT]: To print the release notes on the default printer press or, otherwise, specify another print queue. A message indicates that the file has been queued. 2-4 Installing Distribution Software If you select Option 3, you are first asked to queue the file for printing: * Queue name [SYS$PRINT]: To print the release notes on the default printer press or, otherwise, specify another print queue. A message indicates that the file has been queued. Next, the following message is displayed: VMI$ROOT:[SYSUPD.MS3nnn]MS3$nnn.RELEASE_NOTES;1 The release notes will immediately start scrolling on your terminal. After the system's queue message and after the release notes are displayed (if you selected one of the display options), the procedure continues. VMSINSTAL asks: * Do you want to continue the installation [NO]? o Digital suggests that you press to stop the procedure and read the release notes. Check for any changes that will affect this installation (VMSINSTAL also places the release notes in the file MS3$nnn.RELEASE_ NOTES in the SYS$HELP directory). If you stop VMSINSTAL to read the release notes, run the procedure again when you are ready to continue. Enter: $@VMSINSTAL MS3 device-identifier Here, device-identifier is the device on which the distribution medium is mounted. o If you type Y, VMSINSTAL continues with: %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]? Installing Distribution Software 2-5 Enter to allow the IVP to execute after the installation is complete. %VMSINSTAL-I-RESTORE, Restoring product saveset B... %VMSINSTAL-I-MOVEFILES, Files will now be moved to target directories... If you selected to run the IVP, the following will appear on the terminal: Beginning installation verification procedure for MUXserver 300 Vn.n. Successful creation of SYS$COMMON:[DECSERVER] directory Successful installation of SYS$COMMON:[DECSERVER]MS4801ENG.SYS Successful installation of SYS$COMMON:[DECSERVER]DSVCONFIG.COM Successfully located SYS$COMMON:[DECSERVER]DSVCONFIG.DAT Successful installation of SYS$COMMON:[DECSERVER]MS3_nnn__DEFAULTS.COM Successful installation of SYS$COMMON:[DECSERVER]TSM$MS3_V12_GET_CHAR.COM MUXserver Vn.n Installation Verified. You have finished the first part of the installation. The procedure continues: o It tells you that the installation is complete, meaning that the distribution files have all been copied to their appropriate directories. o It instructs you on how to continue. This is the remainder of VMSINSTAL: Your installation is now complete. After exiting from VMSINSTAL: 1. Edit the system start-up file to define 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. 2-6 Installing Distribution Software This command ensures that the location of the server image is defined each time the system is re-booted, which is 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 only configure any additional units. All previously defined units will still be configured. Installation of MS3 Vn.n completed at hh:mm VMSINSTAL procedure done at hh:mm $ To find the current search string, enter: $SHOW LOG MOM$LOAD After you have edited the file, run the configuration procedure, DSVCONFIG.COM, to configure the load host's node database. Refer to Chapter 3 for information on this procedure. 2.6 Installing onto Alternate Load Hosts Digital recommends that you establish alternate load hosts for each server. As with the original load host an alternate load host must be a DECnet Phase IV system. To serve as an alternate load host, a system must also have the distribution software installed, and it must have entries for one or more servers in its node database. If the original load host is unavailable for down-line loading the server image, any alternate load host can load the server instead. In addition, alternate load hosts can receive up-line dumps from servers and can perform other maintenance functions. Installing Distribution Software 2-7 2.6.1 Installing onto Single Systems To install the server distribution software onto an alternate load host that is not a member of a VAXcluster, use one of the following three methods: o Place your distribution media on the appropriate device of the new load host and repeat the installation procedure detailed in Section 2.5.1. o Copy the distribution files from the original load host to a new load host. Note that these files require 1000 blocks of disk space. o Execute VMSINSTAL. 2.6.2 Installing onto VAXclusters To install the server distribution software onto an alternate load host that is a member of a VAXcluster, install the software onto one cluster member and: o Log into a privileged (system) account on one of the other members of the cluster. o Enter the following command: $ DEFINE/SYSTEM/EXEC/NAME_ATTRIBUTE=NO_ALIAS/NOLOG MOM$LOAD - current-search-string, SYS$SYSROOT:[DECSERVER] o Include the above command in the node's system start-up procedures. 2.6.3 Installing onto Other Operating Systems To install the server distribution software onto another operating system follow the instructions in the MUXserver 300 Software Installation Guide for that system. 2-8 Installing Distribution Software 2.7 Installation Verification Procedure The MUXserver 300 Installation Verification Procedure (IVP) can be executed at any time by entering the command: @SYS$TEST:MS3$IVP If the MUXserver 300 software is installed the output is: Beginning installation verification procedure for MUXserver 300 Vn.n Successful creation of SYS$SYSROOT:[DECSERVER] directory Successful installation of SYS$SYSROOT:[DECSERVER]MS4801ENG.SYS Successful installation of SYS$SYSROOT[DECSERVER]DSVCONFIG.COM Successfully located SYS$SYSROOT:[DECSERVER]DSVCONFIG.DAT Successful installation of SYS$SYSROOT:[DECSERVER]MS3_nnn_DEFAULTS.COM Successful installation of SYS$COMMON:[DECSERVER]TSM$MS3_V12_GET_CHAR.COM MUXserver 300 Vn.n Installation verified Installing Distribution Software 2-9 Chapter__3______________________________________________________ Configuring the Load Host's Node Database 3.1 Introduction This chapter describes the procedures for configuring a load host's node database to support specific servers. Use DSVCONFIG.COM, an automated, menu-driven procedure to define servers in the load host's node database. With DSVCONFIG you can define, delete, and modify entries for any server in the DECserver or MUXserver family. The installation procedure copies this procedure file to the SYS$SYSROOT:[DECSERVER] directory for both single systems and for VAXcluster member nodes (refer to Chapter 2). Note DSVCONFIG.COM, supplied with the distribution kit, accommodates various terminal servers, including the DECserver 100, 200 and 500 and the MUXserver 100 and 300. With DSVCONFIG, you can: o List servers that are currently defined in the load host's node database. o Add an entry for a new server in the load host's node database. Adding an entry supplies information that identifies the server on the Ethernet. o Swap an existing server for a new one or redefine an existing server's identification in the load host's node database. Configuring the Load Host's Node Database 3-1 Swapping retains the DECnet node address of an existing server, replacing its Ethernet address with the Ethernet address of a new unit. This option also can replace other server identifiers either for a new server or for an existing one. o Delete an entry for an existing server from the load host's node database. Deleting an entry prevents the load host from recognizing the server. Thus, it is no longer a load host for that server. You can delete a database entry when you reconfigure the network or assign a server to another load host. 3-2 Configuring the Load Host's Node Database o Restore existing servers to your DECnet load database Restoring copies server entries from the load host's node database to the DECnet load database. Restoring is useful when you routinely copy your local DECnet database from a central DECnet database and that central database does not include servers. The functions of adding, swapping and deleting entries in the DSVCONFIG.DAT file is what is meant by configuration of the load host's node database. In addition, the function of restoring reconfigures the DECnet load database. The DSVCONFIG procedure operates on the following two distinct databases: o The load host's node database. This database is also the server database. It contains the information displayed when you select Option 1, List, from the DSVCONFIG menu. o The DECnet load database. DSVCONFIG operates on both the volatile and the permanent DECnet databases. When you run DSVCONFIG, data is sometimes transferred from the load host's node database to the DECnet database. The DSVCONFIG procedure automatically keeps these databases synchronized. Even though DSVCONFIG includes several NCP commands, do not directly execute these commands yourself in order to configure the load host's node database because NCP affects only the DECnet database. DSVCONFIG also 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. Configuring the Load Host's Node Database 3-3 3.2 Preparing to Run the Configuration Procedure Before beginning the configuration procedure, check that: o DECnet Phase IV is running. For information on DECnet Phase IV, refer to the DECnet VAX Network Management Concepts and Procedures Manual. o There is a unique DECnet node name and node address for each server. To find out the node name and the node address and to determine that they are unique, ask your network manager or the person whose responsibility it is to assign node names and node addresses. You can also determine uniqueness with the NCP SHOW NODE command as follows: $ MCR NCP NCP> SHOW NODE node_name CHARACTERISTICS or NCP> SHOW NODE node_number CHARACTERISTICS o You know the Ethernet address of each server. This is the unique hardware address of each server. The Ethernet address is recorded on the Control/Indicator Panel of the MUXserver 300 and on the Identification Card for that server that you get from the hardware installer. o The directory SYS$COMMON:[DECSERVER] exists, for VAXcluster nodes. If not, create this directory now. You will need the preceding information to answer prompts during DSVCONFIG. 3-4 Configuring the Load Host's Node Database 3.3 DSVCONFIG Conventions and Requirements DSVCONFIG is an interactive procedure. When you run DSVCONFIG a menu of options is displayed. Enter a menu number and press to activate the option you want. After each query, you can get help by pressing the question mark (?). When you finish an option the program returns you to the DSVCONFIG menu. If you want to exit an option without making any changes enter . You are returned to the DSVCONFIG menu. At the menu level type to exit DSVCONFIG and return to the DCL prompt. At the end of the Add, Delete, and Swap options you may get NCP messages (information, confirmations and errors). In the case of error messages the operation may not have been successful. For the meanings of these messages, refer to the VAX/VMS System Messages and Recovery Procedures Reference Manual. To run DSVCONFIG on a single system, the distribution software must already be installed on to that system. For a VAXcluster node, the distribution software can be installed on to any node of the cluster, not necessarily the node where you run the procedure. 3.4 Running DSVCONFIG Log into the system account, or any account with OPER and SYSPRV privileges. Enter the following commands: $ SET DEFAULT SYS$SYSROOT:[DECSERVER] $ @DSVCONFIG DSVCONFIG determines whether DECnet is running and NCP is installed. If DECnet is down or NCP is missing, DSVCONFIG displays a warning and halts the procedure. Configuring the Load Host's Node Database 3-5 If you receive a warning, exit DSVCONFIG and correct the problem. Then run the procedure again, select the option that generated the warning, and repeat the last entry. Next, the procedure checks the existence and format of a data file called DSVCONFIG.DAT. It finds one of three situations and continues accordingly: o SYS$SYSROOT:[DECSERVER] already has this file if DSVCONFIG was previously used to add DECserver 100 entries in this load host's node database. However, the file is not formatted to accommodate MUXserver 300s. The procedure now reformats the file. o SYS$SYSROOT:[DECSERVER] already has this file if DSVCONFIG was previously used to add DECserver 200, MUXserver 100 or MUXserver 300 entries in this load host's node database. The file is formatted correctly so the procedure simply continues with its next task. If DSVCONFIG.DAT file does not exist in SYS$SYSROOT:[DECSERVER], the DSVCONFIG procedure now creates DSVCONFIG.DAT. If DSVCONFIG.DAT has to be created, the following message is displayed: The database file, DSVCONFIG.DAT could not be found, a new one will be created for you. If DSVCONFIG.DAT has to be reformatted, you are asked for a service circuit_ID: The database file DSVCONFIG.DAT must be reformatted for common server use. Enter the service circuit_ID for all existing MUXservers, ? for help or enter CTRL/Z to exit this procedure: Specify one service circuit_ID for all existing DECservers /MUXservers. The default service circuit_ID depends on the default Ethernet controller type for your processor type. 3-6 Configuring the Load Host's Node Database After you specify the service circuit_ID for existing MUXserver 300s and press the following message is displayed: Your DECserver database is being converted, please wait... The DECserver database conversion is now complete... If DSVCONFIG.DAT already exists with the correct format the procedure continues. Once the data file you need exists in the correct format, the procedure proceeds by informing you that each server must have a unique DECnet node name (if it is intended that the host will receive software dumps from the MUXserver 300) and DECnet node address. Then, DSVCONFIG asks you either to continue or to exit: Press RETURN to start or CTRL/Z to exit... Press . DSVCONFIG displays: DECserver Configuration Procedure 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? Enter the number that corresponds to the option you want and press . Configuring the Load Host's Node Database 3-7 3.4.1 List Known Servers (Option 1) Type 1 and press to list the DECservers in the load host's node database. The contents of the DSVCONFIG.DAT file are displayed in seven columns. With Option 1, the listing appear as: DECnet DECnet Server Service Address Name Type Circuit Ethernet Address Load File Dump File ----------------------------------------------------------------------------- 28.1001 TUNA DS200 UNA-0 08-00-2B-02-24-2B PRO801ENG.SYS DS2TUNA.DMP 28.1002 SHRIMP MS100 UNA-0 08-00-2B-04-AA-2B MS1601ENG.SYS MS1SHRIMP.DMP 28.1003 CONCH DS100 UNA-0 08-00-2B-02-24-F1 PS0801ENG.SYS PSDMP24F1.SYS 28.1005 OYSTER MS300 UNA-1 08-00-2B-04-AA-55 MS4801ENG.SYS MS3OYSTER.DMP Total of 4 DECservers defined. This information comprises the load host's node database which the load host uses for down-line loading and for receiving up-line dumps. When a server up-line dumps its memory, which it does upon unexpected failure or upon request by the server manager, the data is dumped into the server dump file. This file can then be used for diagnostics. If a fatal bug check generates an up-line dump, you should copy the dump file to magnetic tape and send it with a Software Performance Report (SPR) to Digital (the server manager may also ask you for a copy of the dump file). Each server has a unique dump file name. The name for MUXserver 300s has the format: MS3xxxxxx.DMP Here, xxxxxx is the DECnet node name of the server. For example, a MUXserver 300 with the DECnet node name SHRIMP has the dump file name MS3SHRIMP.DMP. 3-8 Configuring the Load Host's Node Database 3.4.2 Add a Server (Option 2) Type 2 and press to create a new entry in the load host's node database for a new server. When defining a new entry you must supply: o The server type o A unique DECnet node name for the MUXserver o A unique DECnet node address for the MUXserver o The Ethernet address of the MUXserver o The service circuit_ID Five prompts ask you for this information as follows: DECserver type? Specify the type of server you are adding: MS100 to add a MUXserver 100 MS300 to add a MUXserver 300 DECnet node name for unit? Specify the DECnet node name for the server. This name must begin with a letter and contain from 1 to 6 alphanumeric characters, and it must be unique to your entire DECnet network. DECnet address for unit? Specify the DECnet node address for the server. This number must be a decimal number from 2 to 1023 unique within the network. Your DECnet network may be divided into areas. If this is the case, find out from your network manager your area number, because this number becomes part of each node address. With defined areas each node address takes the form aa.nnnn. Configuring the Load Host's Node Database 3-9 Here, aa is a decimal number from 1 to 63. The period distinguishes area from node address and nnnn is the node address (for example, 7.103). If you omit the area, the area of the current load host is used as a default. DECserver Ethernet address of this unit? Specify the Ethernet address of the server. This address is listed on the Control/Indicator Panel of the unit and on the Network Identification Card for that server that you get from the hardware installer. Enter the Ethernet address as six pairs of hexadecimal digits with hyphens (-) separating the pairs (for example, 08-00-01-00-AB-CB is a valid format). DECnet Service Circuit-ID [default-id]? Specify the service circuit_ID of your Ethernet controller type. Whenever you run this procedure, you may be asked to specify the service circuit_ID several times. The first time you are asked the default will be the service circuit_ID for the processor type of your VMS load host. If you respond by specifying a different service circuit_ID, that response becomes the new default. After you specify the service circuit_ID and press , DSVCONFIG adds the entry for the new server to the database and sets SERVICE ENABLED on the circuit supporting the Ethernet controller, both of which are necessary in order for the load host to downline load the server image to the server. Note If you get an error from DECnet while you are adding a server, the entry is added to the DSVCONFIG.DAT file (the load host's node database) even though it is not entered in the DECnet load 3-10 Configuring the Load Host's Node Database database. You should immediately use Option 4 to delete the entry, fix the condition causing the DECnet error, then return to Option 2 to add the server again. If you specify a node address that is already defined in the server database (the load host's node database), you get a DSVCONFIG error, nothing is added and the Add option is terminated. 3.4.3 Swap an Existing Server (Option 3) Type 3 and press to swap an existing server with a new unit. Swapping retains the DECnet node address of the original unit. Swapping is useful if an existing unit malfunctions and you need to replace it. Swapping is also helpful for renaming servers. DSVCONFIG lets you specify all the following characteristics for the new unit: _____________________________________________________________ Characteristic__Default______________________________________ DECserver type The type of the old DECserver you are replacing DECnet node The name of the old DECserver you are name replacing Ethernet There is no default. You must specify the address Ethernet address of the new unit. DECnet service The service circuit circuit______________________________________________________ First, you are prompted for the node name: What is the DECnet node name you want to swap? Configuring the Load Host's Node Database 3-11 Specify the node name of the existing MUXserver that you want to replace. DSVCONFIG responds by displaying the Ethernet address of the old unit and then asks four questions: DECserver at Ethernet Address nn-nn-nn-nn-nn-nn is being swapped. Enter the new Ethernet address and any other changed characteristics. DECserver type [default-type]? Press if you are replacing a MUXserver 300 with a MUXserver 300. If you are changing MUXserver types, specify the type of the new unit and press . Valid responses are: MS100 for a new MUXserver 100 MS300 for a new MUXserver 300 DECnet node name for unit [default-name]? Press if you want the replacement MUXserver to have the same DECnet node name as the old unit. If you are changing node names, specify the node name of the new unit and press . A MUXserver 300's DECnet node name must begin with a letter and contain from 1 to 6 alphanumeric characters; the name must be unique to your entire DECnet network. DECserver Ethernet address of this unit? You must specify the Ethernet address of the new MUXserver. This address is shown on the Control/Indicator Panel of the unit and on the Identification Card for that server that you get from the hardware installer. Enter the Ethernet address as six pairs of hexadecimal digits, with hyphens (-) separating the pairs (for example, 08-00-01-00-AB-CD is a valid format). Press . DECnet Service Circuit_ID [default_id]? 3-12 Configuring the Load Host's Node Database Press if the replacement MUXserver has the same service circuit_ID as the old unit. If the service circuits are different, specify the service circuit_ID of the new unit and press . After you specify the service circuit_ID and press , DSVCONFIG swaps the characteristics you just specified with the old ones for the server entry with the same DECnet node address (this address cannot be swapped). 3.4.4 Delete an Existing MUXserver (Option 4) Type 4 and press to remove a server from the database. Deleting is useful if you are reconfiguring the network or changing load hosts for a server. DSVCONFIG asks for the DECnet node name: DECnet node name is to be deleted? (CTRL/Z to return to menu) Specify the DECnet node name of the DECserver you want to remove and press . DSVCONFIG checks that the name you specified is an entry in the load host's node database. Then it deletes this entry and tells you of the successful removal. 3.4.5 Restore Existing MUXservers (Option 5) Type 5 and press to restore your load host's DECnet database to include the servers in its node database. The Restore option affects both the volatile and permanent DECnet databases. If your DECnet network contains a large number of nodes you may 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 advises that you not define these servers in that central DECnet database. Configuring the Load Host's Node Database 3-13 If servers are not defined in the central database you must also reconfigure them whenever you copy your local DECnet database from this central DECnet database. Each time you copy the central DECnet database, use Option 5 to restore existing server configurations. The following messages confirm the restoration: Restoring existing DECservers from local database... Local database successfully restored. 3.4.6 Restoring from a Command Procedure There is another way, which can be automated, to restore your local DECnet database. Run DSVCONFIG.COM with the RESTORE parameter: $@DSVCONFIG RESTORE Using the RESTORE parameter bypasses the menu and allows you to include the configuration procedure in your system start-up procedures. If you want to restore the down-line load database (the DECnet load database) for your servers at system startup, edit your system start-up file. Include the following statement after the line @SYS$MANAGER:RTLOAD: @SYS$SYSROOT:[DECSERVER]DSVCONFIG RESTORE 3.5 Down-Line Loading the Server Image After you have completed the configuration procedure verify the Load Host Installation by down-line loading the new server image from the load host to the server. Refer to Chapter 4 for information on this procedure. 3-14 Configuring the Load Host's Node Database Chapter__4______________________________________________________ Verifying the Installation 4.1 Introduction This chapter describes the procedures for performing two verifications. Firstly, it describes verification of the load host installation by down-line loading the server image. Secondly it describes how to verify the server as a system after it is loaded by testing a few server commands at an interactive terminal, which must be connected to the server. To complete the software installation you need to perform the following two verifications: o To verify the installation of the load host, down-line load the server image to one MUXserver 300 and then read the DECnet event logging messages. These steps confirm that the new load host: * Has the appropriate files in the correct directory. * Has a correct entry in its node database for the server. * Can successfully down-line load the server image to the server. o To verify the total server system installation test a few server commands as illustrated later in this chapter, at an interactive terminal connected to a supervisor port. System installation means the installation of the complete server system-the hardware unit with the correct software loaded and running. This step confirms that: * The correct version of the software is in the server. * The server hardware operates with the new software. Verifying the Installation 4-1 * The new software is running successfully. 4.2 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. Even though there are several ways to down-line load the server image, use the NCP LOAD NODE command to verify the installation. This is the only method that tests the installation of the software from a specific load host (a discussion of all the ways to down-line load appears in the MUXserver/DECmux 300 Network Reference Manual). With the LOAD NODE command you can: o Specify a load host. This ensures that the load host which performs the down- line load is your VMS system. o Read the DECnet event-logging messages. These messages confirm that the specified load host performed the down-line load successfully. You may 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. 4.2.1 Loading a New Server If a server is new it 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. 4-2 Verifying the Installation The hardware installer can then verify the hardware installation with the appropriate diagnostic light emitting diodes on the MUXserver 300 hardware unit(s). 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, 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.2.2 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, coordination with the server manager is important. Digital 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 this is considered necessary. The MUXserver/DECmux 300 Network Reference Manual discusses the issues involved in shutting down the server. 4.2.3 Loading After Hours You and the server manager can perform the down-line load after hours to minimize disruption to the nodes affected by the server. If so, you can put the LOAD command in a batch job and run it at night. Verifying the Installation 4-3 4.2.4 Warning Users before Loading To reload an installed and running MUXserver during normal working hours, either you (if you know the password) or the server manager can use the server interface to issue the privileged BROADCAST ALL command to warn server users. You can also broadcast the warning on a remote console port. Appendix B contains information on using the Remote Console Facility 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, may not receive your message. 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 commands send the message: "The server will be reloaded in 3 minutes," to all the ports. Local> ATTACH ALL Local> BROADCAST ALL "The server will be reloaded in 3 minutes." 4.2.5 Down-Line Loading with the LOAD Command Down-line loading the server image for load host verification involves three steps: o Prepare for the LOAD command by checking the DECnet node name or DECnet node address of the server, by checking if the server has a DECnet service password, and by enabling DECnet event logging. In addition, if you are reloading an existing server, warn the interactive users. o Issue the LOAD command. o Read the event-logging message that reports the down-line load. 4-4 Verifying the Installation 4.2.5.1 Preparing for the LOAD Command To prepare for down-line loading: 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 (refer to Chapter 3), run the procedure again, and select the LIST option from the menu. LIST displays the DECnet node name and DECnet node address of all the servers you defined in this load host's node database. 2. Find out the server's DECnet service password, if there is one, from the server manager (the 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 the following commands: $ MCR NCP NCP> SET LOGGING CONSOLE EVENT 0.3,7 NCP> SET LOGGING CONSOLE STATE ON NCP> SET LOGGING MONITOR STATE ON 4. If you are reloading an existing server, warn the interactive users with the BROADCAST command. Refer to Section 4.2.4 for information on issuing the BROADCAST command. Note All the other commands needed for down-line loading, such as the ones that set the Ethernet line and identify the service circuit, are part of DSVCONFIG and are executed when you run that procedure (see Chapter 3). In addition, SERVICE Verifying the Installation 4-5 must be enabled on the service circuit which is also performed by DSVCONFIG. 4.2.5.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 SHRIMP with a node address of 13.204. $ MCR NCP NCP> LOAD NODE SHRIMP or NCP> LOAD NODE 13.204 If the server manager previously set a server maintenance password, include the SERVICE PASSWORD keywords and specify this password as the DECnet service password on the command line. For example: NCP> LOAD NODE SHRIMP SERVICE PASSWORD OF23 To exit from NCP, type EXIT: NCP> EXIT $ 4.2.6 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's operator's console. They identify your VMS system as the node that generated the event. 4-6 Verifying the Installation If no errors are reported you can assume that the down-line load was successful and you have finished the verification of the new load host. Appendix C contains an example of DECnet event logging after a successful down-line load. If the event-logging messages report errors, 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 and enter 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 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.3 Verifying the Server System Installation Using a number of server commands at an interactive terminal attached to the server console port completes your verification of the server system installation. Apply the following sequence: 1. Press a number of times The following message and prompt appear: MUXserver 300 Terminal Server V1.2 (BL2x) - LAT V5.1 Please type HELP if you need assistance Enter username> Verifying the Installation 4-7 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: o With the load host o With the terminal o That the incorrect software was down-line loaded 3. Enter your user name (any string of 1 through 16 characters that identifies you) and press . The port should now enter local mode, where the (Local>) prompt 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 You can interrupt this test by pressing . Appendix C contains 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 contains an example of a port-characteristics display. 4-8 Verifying the Installation 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 contains 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 VSYSTEM: Local> CONNECT VSYSTEM When the server successfully connects your terminal to the service you specified, you should no longer see the local prompt; you should be 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 or log out from the service to return to local mode. 10.Log out from the server then 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, Verifying the Installation 4-9 either you or the server manager must now reload all existing servers. 4-10 Verifying the Installation Appendix__A_____________________________________________________ MUXserver 300 Distribution Files The following files are included in the MUXserver 300 Distribution Kit: File Name Description KITINSTAL.COM Command file used by VMSINSTAL during installation DSVCONFIG.DAT Empty configuration file DSVCONFIG.COM Configuration procedure MS3$nnn.RELEASE_ MUXserver/DECmux 300 release notes, NOTES nnn=version number MS3_nnn_ TSM command file to set a MUXserver 300 DEFAULTS.COM to factory defaults MS4801ENG.SYS MUXserver/DECmux 300 software image TSM$MS3_V12_GET_ TSM command file to create a file of CHAR.COM MUXserver 300 parameter settings (new for Version 1.2) MUXserver 300 Distribution Files A-1 . A-2 MUXserver 300 Distribution Files Appendix__B_____________________________________________________ Using the Remote Console Facility The MUXserver/DECmux 300 network supports the VMS Remote Console Facility (RCF). This Appendix describes its use from a VMS host. RCF could be used to issue the BROADCAST command to warn users of a planned down-line load. 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. $MCR NCP NCP> CONNECT NODE SHRIMP SERVICE PASSWORD 0F23 Console connected (press CTRL/D when finished) or NCP>CONNECT NODE 13.204 SERVICE PASSWORD 0F23 Console connected (press CTRL/D when finished) Press to start the login sequence for the remote console. 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 QNA-0 to a server with the Ethernet address 08-00-2B-04-AA-2B: NCP>CONNECT VIA QNA-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. Using the Remote Console Facility B-1 To exit from RCF, type Local> To exit from NCP, type EXIT: NCP>EXIT $ 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 appears, and control returns to NCP on your VMS system (refer to the MUXserver/DECmux 300 Network Reference Manual). B-2 Using the Remote Console Facility Appendix__C_____________________________________________________ Installation, Configuration & Verification Examples C.1 Introduction This Appendix provides examples of installation and config- uration procedures. It also illustrates the verification of a load host installation by down-line loading and reading DECnet event-logging messages. Finally, it shows the veri- fication of a server system installation by testing server commands. C.2 Example of an Installation The following example illustrates a successful installation onto a VMS V5.2 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, extra prompts during the procedure instruct you to mount additional volumes. This example also shows the procedure as DIGITAL suggests you run it: o Use the option that prints the release notes. o Print the release notes. o Stop the procedure to read them. o Re-run the procedure. Installation, Configuration & Verification Examples C-1 $ SET DEFAULT SYS$UPDATE $ @VMSINSTAL MS3 $1$MUA0: OPTIONS N VAX/VMS Software Product Installation Procedure V5.2 It is 15-JAN-1990 at 15:52. Enter a question mark (?) at any time for help. * Are you satisfied with the backup of your system disk [YES]? The following products will be processed: MS3 V1.2 Beginning installation of MS3 V1.2 at 15:53 %VMSINSTAL_I_RESTORE, Restoring product saveset A ... Release notes included with this kit are always copied to SYS$HELP. Additional Release Notes Options: 1. Display release notes 2. Print release notes 3. Both 1 and 2 4. None of the above * Select option [2]: * Queue name [SYS$PRINT]: Job MS3$012 (queue SYS$PRINT, entry 314) started on SYS$PRINT * Do you want to continue the installation [NO]? VMSINSTAL procedure done at 15:55 $ Read the release notes and run VMSINSTAL again: $ @VMSINSTAL MS3 $1$MUA0: OPTIONS N VAX/VMS Software Product Installation Procedure V5.2 It is 15_JAN_1990 AT 16:05. Enter a question mark (?) at any time for help. * Are you satisfied with the backup of your system disk [YES]? C-2 Installation, Configuration & Verification Examples The following products will be processed: MS3 V1.2 Beginning installation of MS3 V1.2 at 16:03 %VMSINSTAL-I-RESTORE, Restoring product saveset A ... Release notes included with this kit are always copied to SYS$HELP. Additional Release Notes Options: 1. Display release notes 2. Print release notes 3. Both 1 and 2 4. None of the above * Select option [2]: < 4 > * Do you want to continue the installation [NO]? < Y > %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 ... %VMSINSTAL_W_MOVEFILES, Superseded version of DSVCONFIG.COM exists, file copied as SYS$COMMON[DECSERVER]DSVCONFIG.COM_V12 %VMSINSTAL-I-MOVEFILES, Files will be moved to their target directories... Beginning installation verification procedure for MUXserver 300 V1.2. Successful creation of SYS$COMMON:[DECSERVER] directory Successful installation of SYS$COMMON:[DECSERVER]MS4801ENG.SYS Successful installation of SYS$COMMON:[DECSERVER]DSVCONFIG.COM Successfully located SYS$COMMON:[DECSERVER]DSVCONFIG.DAT Successful installation of SYS$COMMON:[DECSERVER]MS3_010_DEFAULTS.COM Successful installation of SYS$COMMON:[DECSERVER]TSM$MS3_V12_GET_CHAR.COM MUXserver 300 V1.2 Installation Verified Your installation is now complete. After exiting from VMSINSTAL: Installation, Configuration & Verification Examples C-3 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. Installation of MS3 V1.2 completed at 16:08 VMSINSTAL procedure done at 16:08 $ C.3 Configuration Examples Note DSVCONFIG.COM is a command procedure used with all DIGITAL terminal servers. All references to DECservers include the MUXserver 100 and the MUXserver 300. C-4 Installation, Configuration & Verification Examples C.3.1 Starting DSVCONFIG.COM The following example shows the beginning of the configura- tion 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. (Refer to Chapter 3 for the prompts that are displayed if the procedure has either to create DSVCONFIG.DAT or be reformatted.) $ SET DEFAULT SYS$SYSROOT:[DECSERVER] $ @DSVCONFIG You must assign a unique DECnet node name and DECnet node address for each DECserver. Press RETURN to start, or CTRL/Z to exit... DECserver Configuration Procedure Menu of Options C.3.2 The DSVCONFIG.COM Menu This example illustrates the DSVCONFIG Menu. DECserver Configuration Procedure 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? Installation, Configuration & Verification Examples C-5 C.3.3 Listing Known Servers (Option 1) The following sections show how the configuration procedure continues for each option. With the exception of List, each option ends by automatically returning to the menu. Your selection? < 1 > DECnet DECnet Server Service Address Name Type Circuit Ethernet Address Load File Dump File ____________________________________________________________________________ 28.1001 TUNA DS200 UNA-0 08-00-2B-02-24-AA PRO801ENG.SYS DS2TUNA.DMP 28.1003 CONCH MS100 UNA-0 08-00-2B-02-24-F1 MS1601ENG.SYS MSDMP24F1.SYS 28.1005 OYSTER MS300 UNA-1 08-00-2B-04-AA-2B MS4801ENG.SYS MS3OYSTER.DMP Total of 3 DECservers defined. C.3.4 Adding a Server (Option 2) This example adds a new MUXserver 300 named SHRIMP. 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? MS300 DECnet node name for unit? SHRIMP DECnet address for unit? 28.1002 DECserver Ethernet address of this unit? 08-00-2B-04-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 SHRIMP appears on the listing of entries. C-6 Installation, Configuration & Verification Examples C.3.5 Swapping a MUXserver 300 for a New Unit (Option 3) In this example an existing MUXserver 300 named CONCH is swapped for a new MUXserver 300, 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. Note that if you use Swap a MUXserver 300, you will have to specify the new MUXserver 300's Ethernet address. Your selection? < 3 > Type a ? at any time for help on 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? CONCH DECserver at Ethernet address 08-00-2B-02-24-F1 is being swapped. Enter the new Ethernet address, and any other changed characteristics. DECserver type? [DS100] MS300 DECnet node name for unit? [CONCH] DECserver Ethernet address of this unit? 08-00-2B-03-AA-AB DECnet Service Circuit-ID? [UNA-0] C.3.6 Deleting a 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 TUNA. Your selection? < 4 > Which DECnet node name is to be deleted? (CTRL/Z returns to menu) TUNA %NCP-I-NMLRSP, listener response - Success Remote node = 28.1001 (TUNA) %NML-I-RECDELET, Database entry deleted If you use the List option to get a listing of servers, you see that TUNA no longer appears. Installation, Configuration & Verification Examples C-7 C.3.7 Restoring Existing Servers to the Database (Option 5) This example shows the restoration of the local down-line load database. Your selection? < 5 > Restoring existing DECservers from local database... Local database successfully restored. C.4 Verification Examples C.4.1 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 VSYSTEM. The server that is loaded is a MUXserver 300 with DECnet node name SHRIMP. SHRIMP 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.4.2 Using RCF and Warning Server Users This example uses the server's default login password, ACCESS. $ MCR NCP CONNECT NODE SHRIMP SERVICE PASSWORD OF23 Console connected (press CTRL/D when finished) # ACCESS (not echoed) MUXserver 300 Terminal Server Vn.n (BL2x) - LAT V5.1 Please type HELP if you need assistance Enter username> SWINSTALLER C-8 Installation, Configuration & Verification Examples Local> BROADCAST ALL "The server will be reloaded in 3 minutes." Local> $ C.4.3 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 SYS$SYSROOT:[DECSERVER] $ @DSVCONFIG You must assign a unique DECnet node name and DECnet node address for each DECserver. Press RETURN to start, or CTRL/Z to exit... DECserver Configuration Procedure 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 SHRIMP MS300 UNA-0 08-00-2B-04-AA- 2B MS4801ENG.SYS MS3SHRIMP.DMP Total of 1 DECserver defined. DECserver Configuration Procedure Installation, Configuration & Verification Examples C-9 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.4.4 Down-Line Loading with the LOAD Command $ MCR NCP LOAD NODE SHRIMP PASSWORD OF23 C.4.5 DECnet Event-Logging Display after Issuing LOAD NCP> LOAD NODE SHRIMP SERVICE PASSWORD OF23 DECnet event 0.3, automatic line service From node 4.205 (VSYSTEM), 18-JUN-1988 01:35:20.47 Circuit UNA-0, Load, Requested, Node = 28.1002 (SHRIMP) File = MOM$SYSTEM_SOFTID:MS4801ENG, Operating system Ethernet address= 08-00-2B-04-AA-2B DECnet event 0.3, automatic line service From node 4.205 (VSYSTEM), 18-JUN-1988 01:43:21.14 Circuit UNA-0, Load, Successful, Node = 28.1002 (SHRIMP) FILE = MOM$SYSTEM_SOFTID:MS4801ENG, Operating system Ethernet address= 08-00-2B-04-AA-2B C.4.6 Conclusion of a Load Host Installation Verification NCP> CLEAR LOGGING CONSOLE EVENT 0.3,7 NCP> EXIT $ C-10 Installation, Configuration & Verification Examples C.4.7 Verifying the Server System Installation This example illustrates 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 console port, that your username is SWINSTALLER, that your user password is SQUIDS, that you will test the server by connecting to your own VMS system, VSYSTEM, and that the new MUXserver 300 software is Version 1.2. MUXserver 300 Terminal Server Vn.n (BL2x) - LAT V5.1 Please type HELP if you need assistance Enter username> SWINSTALLER Local> TEST PORT COUNT 5 WIDTH 65 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^__` !"#S%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^__`a "#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^__`ab #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^__`abc $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^__`abcd Local> SHOW PORT The display at the port of a new MUXserver 300 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 Installation, Configuration & Verification Examples C-11 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 VSYSTEM Connected VAX/VMS 8600 Local> CONNECT VSYSTEM Local -010- Session 1 to VSYSTEM established VSYSTEM -- VAX 8600, the Best for down-line loading Username: SWINSTALLER Password: SQUIDS (not echoed) Welcome to VAX/VMS version 5.2 on node VSYSTEM Last interactive login on Monday, 15-JAN-1990 15:50 Last non-interactive login on Friday, 15-DEC-1989 09:18 SYS$MANAGER:NOTICE.TXT - VSYSTEM System Notices 18-Jun-1988 All Users, please purge your files! C-12 Installation, Configuration & Verification Examples $ SHOW TIME 16-JAN-1990 13:55:27 $ SHOW USERS VAX/VMS User Processes at 16-JAN-1990 13:55:36.33 Total number of users = 4, number of processes = 5 Username Interactive Subprocess Batch IVY 1 ROSE 1 SRV$SYSTEM - 1 1 SWINSTALLER 1 $ LO SWINSTALLER logged out at 16-JAN-1990 13:57:30.05 Installation, Configuration & Verification Examples C-13 . C-14 Installation, Configuration & Verification Examples Glossary________________________________________________________ This glossary defines terms used in the MUXserver/DECmux 300 Software Installation Guide for the VMS and MicroVMS operating systems. Asynchronous Pertaining to a communication method in which each event occurs in with no relation to a timing signal. See also synchronous. CCITT International Telephone and Telegraph Consultative Committee, an international standardization body of the Postal, Telephone and Telegraph departments and their equivalents. CRC Cyclic Redundancy Check, an error detection scheme in which the receiver checks each block of data for errors. A check character is generated by taking the remainder after dividing all serialized bits in the block by a predetermined number. This check character is compared with a transmitted check character and, if the two do not match, the block is retransmitted. DEBNA An Ethernet communications controller for computers with VAX BI bus hardware. DEC423 DEC423 is an interface standard developed by Digital. It is electrically compatible with EIA Standard RS-423-A. Glossary-1 DELNI A local network interconnect product that provides eight sep- arate network interfaces from a single Ethernet transceiver. DELQA A communications controller that connects Q-bus MicroPDP11 and MicroVAX systems to an Ethernet or IEEE 802.3 local area network. DELUA A high performance Ethernet communications controller for computers based on the UNIBUS hardware. DEQNA An Ethernet communications controller for computers based on the Q-bus hardware. DESQA A communications controller that connects Q-bus MicroPDP11 and MicroVAX systems in BA200-series enclosures to an Ethernet or IEEE 802.3 local area network. DEUNA An Ethernet communications controller for computers based on UNIBUS. EIA Electrical Industries Association. A USA organization with the same function as CCITT. EIA-232-D EIA Recommended Standard No 232 Issue D (formerly RS-232-C). It defines the connectors, cables and electrical character- istics for an asynchronous serial communications interface between a computer and a modem. It is also widely applied to interfaces between computers and other terminal equipment. Glossary-2 EEPROM Electrically Erasable Programmable Read-Only Memory. EPROM Erasable Programmable Read-Only Memory. Ethernet A Xerox trade mark for a type of local area network based on carrier-sense multiple access/collision detection (CSMA/CD). Ethernet Transceiver A device which attaches to a standard Ethernet coaxial cable. FCC Federal Communication Commission. IEC International Electrotechnical Commission. LAT Local Area Transport - Digital's name for the Ethernet protocol used by the MUXserver 300 for terminal connections. LED Light Emitting Diode Local Area Network A network spanning a limited geographic area, such as a building or group of buildings, and using high speed data bus(es). Logging On The identification of a user to the (VAX/VMS) operating system. The user types an account name and password in response to prompts from the system. Glossary-3 MMJ Modified Modular Jack, an offset-keyed modular jack used for data cables. MODEM The word is a contraction of MOdulator DEModulator. A modem interfaces a terminal to a transmission line. A modem is sometimes called a dataset. Network Manager The person responsible for all components of a network in a particular geographic area. Note that this does not include the MUXserver/DECmux 300 network (see Server Manager). Node An intelligent device on a network. Port The actual physical connection between equipment and, for example, a serial communications line. Repeater A non-intelligent device on a network. Used to extend the length of a medium by restoring signal amplitude, waveform and timing. SER Satellite Equipment Room. Service A resource, such as a computer. Server A hardware and/or software device which provides many users with access to a system. Glossary-4 Server Manager The person responsible for a particular server. This includes a person responsible for a MUXserver/DECmux 300 network which, in this context, is seen as a server. STATMUX Statistical Multiplexing. Supervisor Port A DEC423 port used to connect a test terminal. Synchronous Pertaining to a communication method in which each event occurs in relation to a timing signal. See also Asynchronous. System Manager The person responsible for the policies, procedures and the daily operation of a computer system. TDM Time Division Multiplexing. Terminal An input/output computer peripheral device that has a keyboard and video screen or printer. Terminal Server An active device, such as a MUXserver/DECmux 300 network, used to attach terminals to a host system through a network. ThinWire Ethernet An IEEE 802.3 compliant Ethernet network composed of thin Ethernet cable as opposed to standard Ethernet cable. ThinWire Segment A length of coaxial cable made up of one or more cable sections connected together with BNC barrel connectors and BNC TEE connectors. Glossary-5 Transceiver See Ethernet Transceiver. VMS Digital's VAX computers' main operating system. Glossary-6 Index___________________________________________________________ A______________________________ Deleting a MUXserver, 3-13, Adding a MUXserver, 3-9, C-6 C-7 After-hours software Distribution kit, A-1 initialization, 4-3 Down-line loading Alternate load host definition, 1-7 assignment, 1-4 server image, 3-14 software installation, 2-7 DSVCONFIG conventions, 3-5 B______________________________ introduction, 1-5, 3-1 BROADCAST command, 4-4 preparation, 3-4 running, 3-5 C______________________________ starting, C-5 Configuration options versions, 1-5 option 1, 3-8 E______________________________ option 2, 3-9 Ethernet option 3, 3-11 Addresses, x option 4, 3-13 overview, 1-1 option 5, 3-13 Event logging, 4-6 Connections, 1-2 CONNECT NODE command, B-1 G Conventions, x _______________________________ Graphics conventions, x D______________________________ Database configuration I______________________________ load host, 3-1 Installing distribution DECconnect software, 1-3 cables, 1-2 L DECmux 300 overview, 1-1 _______________________________ DECnet LAT database restoration, 3-14 control program, 1-3 event logging, 4-6, C-9 protocol, 1-2 introduction, 1-5 software, 1-3 Phase IV, 2-1 LATCP, 1-3 LED Index-1 LED (Cont.) S indications, 4-3 _______________________________ List MUXservers, 3-8, C-6 Server image down-line loading LOAD command, 4-3, 4-6, C-10 , 3-14 Load host Service nodes alternate, 1-4 allocation, 2-1 assignment, 1-4 introduction, 1-2 database, 1-5 SERVICE PASSWORD keywords, B-1 database configuration, 3-1 SHOW PORT command, 4-8 installation verification, SHOW SERVICES command, 4-9 4-2 Single systems introduction, 1-3 software installation, 2-8 LOAD NODE command, 4-2 Software initialization LTDRIVER file, 1-3 after-hours, 4-3 warning to users, 4-4 M______________________________ Software installation MUXserver/DECmux 300 alternate load hosts, 2-7 concepts, 1-1 examples, C-1 overview, 1-1 introduction, 1-3 services, 1-2 other operating systems, 2-8 preparation, 2-1 N______________________________ single systems, 2-8 NCP LOAD NODE command, 1-7, system verification, 4-7 4-2 VAXclusters, 2-8 Numbering convention, x verification, 1-7, 4-1 Software verification R existing server, 4-3 _______________________________ new server, 4-2 RCF, B-1, C-8 Swapping MUXservers, 3-11, C-7 Related publications, vii SYS$HELP directory, 2-5 Release notes, 1-5 SYS$SYSROOT:[DECSERVER] Remote console facility, B-1 directory, 2-1 Restoring a MUXserver, 3-13, System installation, 4-1 C-8 Index-2 T software installation, 2-8 _______________________________ Verification TEST PORT command, 4-8 load host installation, 1-7 U server system installation, _______________________________ 1-8 ULTRIX, 1-4 VMSINSTAL command conventions, 2-2 V______________________________ example, C-1 VAXclusters introduction, 1-5, 2-1 running, 2-3 Index-3