____________________________________________________ OpenVMS Alpha Version 7.1-1H1 Release Notes and Installation Procedures Order Number: AA-R85GA-TE October 1997 This document contains release notes and installation information for the OpenVMS Alpha Version 7.1-1H1 operating system. Revision/Update Information: This is a new document. Operating System and Version: OpenVMS Alpha Version 7.1-1H1 Digital Equipment Corporation Maynard, Massachusetts ________________________________________________________________ October 1997 Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from DIGITAL or an authorized sublicensor. DIGITAL conducts its business in a manner that conserves the environment and protects the safety and health of its employees, customers, and the community. © Digital Equipment Corporation 1997. All rights reserved. The following are trademarks of Digital Equipment Corporation: AlphaServer, AlphaStation, DEC, DECdirect, DECevent, DECnet, DECserver, DECterm, DECwindows, Digital, HSZ, InfoServer, MSCP, OpenVMS, POLYCENTER, RZ, ServerWORKS, StorageWorks, TURBOchannel, VAX, VMS, and the DIGITAL logo. The following are third-party trademarks: Microsoft, MS-Windows, and Windows NT are registered trademarks of Microsoft Corporation. Motif, OSF, OSF/1, and OSF/Motif are registered trademarks of the Open Software Foundation, Inc. POSTSCRIPT is a registered trademark of Adobe Systems Incorporated. All other trademarks and registered trademarks are the property of their respective holders. ZK6511 The OpenVMS documentation set is available on CD-ROM. _________________________________________________________________ Contents Preface................................................... v 1 General Release Notes 1.1 Guidelines for Updating and Installing the OpenVMS Alpha Operating System................ 1-1 1.1.1 When to Update............................ 1-2 1.1.2 How to Update............................. 1-3 1.1.3 When to Install........................... 1-3 1.1.4 How to Install............................ 1-4 1.2 Remedial Kits................................. 1-4 1.2.1 Remedial Kits Integrated into Version 7.1-1H1................................... 1-4 1.2.2 Pertinent Remedial Kits That Are Not Integrated into Version 7.1-1H1........... 1-5 1.2.2.1 OpenVMS Cluster Compatibility Kits...... 1-5 1.2.2.2 Volume Shadowing Remedial Kits.......... 1-6 1.2.2.3 MEMORY CHANNEL Remedial Kit............. 1-6 1.2.2.4 Remedial Kit for Alpha Systems with More than 4 GB Memory or with User-Written SCS System Applications................. 1-7 1.3 Ultra SCSI Support............................ 1-8 1.3.1 Coexistence of Ultra SCSI Devices With Other SCSI Devices........................ 1-9 1.4 SCSI Device Naming Using Port Allocation Classes....................................... 1-9 1.4.1 SCSI Device Naming Advisory............... 1-9 1.4.2 Possible Problem with SCSI Device Naming and Quorum Disks.......................... 1-11 1.4.3 SCSI Shared Interconnect Requires Same Node Allocation Class .................... 1-12 1.4.4 SCSI Device Naming Conflict That Prevents Satellite Booting......................... 1-12 iii 1.5 Incorrect Default Value of the MSCP_CMD_TMO System Parameter.............................. 1-13 1.6 Multiprocessor Systems with CIPCAs: SMP_SPINWAIT Restriction ..................... 1-13 1.7 Updating the SRM Console on Digital Modular Computing Components (DMCC)................... 1-14 1.8 After Upgrading or Installing OpenVMS Version 7.1-1H1....................................... 1-15 1.9 Field Replaceable Units (FRU) Table Error on AlphaServer 8200/8400 and 4100 Systems........ 1-16 1.10 DECevent...................................... 1-16 1.10.1 DECevent 2.5-2 Kit........................ 1-16 1.10.2 Change to DECevent DIAGNOSE Command Installation.............................. 1-17 1.10.3 AlphaServer 8200/8400 Systems and DECevent.................................. 1-17 1.11 XDELTA Problem with Newer OpenVMS Systems..... 1-17 1.12 MSCP-Served RRD45 CD-ROM Testing.............. 1-18 1.13 Year 2000 DIGITAL Product Warranty............ 1-20 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha................................. 1-20 1.14.1 Overview of DSM Subagents................. 1-21 1.14.2 Setting Up the System to Use the DSM Subagents................................. 1-50 1.15 Environmental Data Restrictions: AlphaServer 8200 and 8400 Systems......................... 1-52 1.16 Device IIA0: Now Configured on AlphaServer 4100 Systems.................................. 1-53 1.17 Device OPA1: Now Configured on AlphaServer 8200 and 8400 Systems......................... 1-53 2 Updating to OpenVMS Alpha Version 7.1-1H1 2.1 Preparing Your System......................... 2-1 2.2 Preparing to Update Using an InfoServer System........................................ 2-3 2.3 Matching Update Procedures to System Configurations................................ 2-5 2.3.1 Updating OpenVMS Cluster Environments..... 2-5 2.3.2 Updating a Local Area OpenVMS Cluster System with One Boot Server and Two System Disks..................................... 2-6 iv 2.4 Applying the OpenVMS Alpha Version 7.1-1H1 Update........................................ 2-7 2.5 Tasks to Perform After the Update............. 2-10 Tables 1-1 DSM System Subagent Objects Implemented on OpenVMS Alpha............................. 1-22 1-2 DSM Management Subagent Objects Implemented on OpenVMS Alpha.............. 1-37 1-3 DSM Management Subagent Traps Implemented on OpenVMS Alpha.......................... 1-48 v _________________________________________________________________ Preface The OpenVMS Alpha Version 7.1-1H1 operating system is available on a CD-ROM from which you can install or update the operating system. This document describes how to perform either task and includes relevant release notes. Intended Audience This document is intended for anyone responsible for maintaining the OpenVMS Alpha operating system. Document Structure This document is organized as follows: o Chapter 1 includes release notes relevant to this kit. o Chapter 2 describes how to prepare your system for an update, how to use the update procedure, and how to perform post-update tasks. Related Documents You might need to refer to the following documents: o The OpenVMS Alpha Version 7.1-1H1 Cover Letter and the current versions of the OpenVMS and OpenVMS Cluster software product descriptions (SPDs), for information about the specific devices and options supported in this release. The letter is included with the OpenVMS Alpha Version 7.1-1H1 kit and the SPDs are available in text and POSTSCRIPT formats in the documentation directories of the operating system CD-ROM. v o The OpenVMS Alpha Version 7.1 Upgrade and Installation Manual, which describes how to install the operating system from the distribution CD-ROM and how to start up, shut down, halt, and back up your Alpha system. ________________________ Note ________________________ Note that the OpenVMS Alpha operating system CD-ROM also contains the following OpenVMS documentation directories: o [DOCUMENTATION.V0711H1] o [DOCUMENTATION.V071] In addition, other layered product directories and documentation directories are included on the OpenVMS Version 7.1-1H1 CD-ROM. Refer to the OpenVMS Version 7.1-1H1 CD-ROM User's Guide for a complete listing of the directories and documentation. These directories contain text and POSTSCRIPT documents, including software product descriptions (SPDs), the installation manual, and release notes. ______________________________________________________ o The hardware manuals that are supplied with your Alpha computer. These manuals provide detailed information about your system hardware, including the operation of the system unit, the drives, and the monitor. For additional information on the Open Systems Software Group (OSSG) products and services, access the DIGITAL OpenVMS World Wide Web site. Use the following URL: http://www.openvms.digital.com Reader's Comments DIGITAL welcomes your comments on this manual. Print or edit the online form SYS$HELP:OPENVMSDOC_COMMENTS.TXT and send us your comments by: Internet openvmsdoc@zko.mts.dec.com vi Fax 603 884-0120, Attention: OSSG Documentation, ZKO3-4/U08 Mail OSSG Documentation Group, ZKO3-4/U08 110 Spit Brook Rd. Nashua, NH 03062-2698 How To Order Additional Documentation Use the following table to order additional documentation or information. If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825). ______________________________________________________________________ Location Call Fax Write ______________________________________________________________________ U.S.A. DECdirect Fax: 800-234-2298 Digital Equipment 800-DIGITAL Corporation 800-344-4825 Mailstop: TAY2-2/11D 153 Taylor Street Littleton, MA 01460 Puerto Rico 787-781-0505 Fax: 787-749-8300 Local DIGITAL subsidiary Canada DTN: 621-6005 Fax: 613-592-1946 Digital Equipment 800-DIGITAL of Canada, Ltd. Box 13000 Kanata, Ontario Canada K2K2A6 Attn: CICC International - - Local DIGITAL subsidiary or approved distributor Internal DTN: 261-2010 Fax: 800-741-6970 U.S. Software Orders 603-791-2010 Supply Business Digital Equipment Corporation 8 Cotton Road Nashua, NH 03063-1260 ______________________________________________________________________ vii Conventions The following conventions are also used in this manual: ( ) In command format descriptions, parentheses indicate that, if you choose more than one option, you must enclose the choices in parentheses. [ ] In command format descriptions, brackets indicate optional elements. You can choose one, none, or all of the options. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file specification or in the syntax of a substring specification in an assignment statement.) [|] In command format descriptions, vertical bars separating items inside brackets indicate that you choose one, none, or more than one of the options. text style This text style represents the introduction of a new term or the name of an argument, an attribute, or a reason. In the HTML version of this Conventions table, this convention appears as italicized text. viii italic text Italic text indicates important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER=name), and in command parameters in text (where device- name contains up to five alphanumeric characters). UPPERCASE TEXT Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege. Monospace type Monospace type indicates code examples and interactive screen displays. In the C programming language, monospace type in text identifies the following elements: keywords, the names of independently compiled external functions and files, syntax summaries, and references to variables or identifiers introduced in an example. In the HTML version of this Conventions table, this convention appears as italicized text. numbers All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes-binary, octal, or hexadecimal-are explicitly indicated. ix 1 _________________________________________________________________ General Release Notes This chapter contains OpenVMS Alpha Version 7.1-1H1 release notes that you should review before installing or updating the operating system. ________________________ Note ________________________ The primary purpose of the OpenVMS Alpha Version 7.1-1H1 operating system is to provide support for new hardware, so that you can take advantage of these products as soon as possible. This release also contains corrections for certain problems encountered since the release of the OpenVMS Version 7.1 operating system. These corrections are also available in remedial kits. Contact your DIGITAL support representative for remedial kits or if you experience a problem that is not documented in these release notes or the OpenVMS Version 7.1 Release Notes. ______________________________________________________ 1.1 Guidelines for Updating and Installing the OpenVMS Alpha Operating System The following sections provide information about updating to and installing the OpenVMS Alpha Version 7.1-1H1 operating system. ________________________ Notes ________________________ Before you use the update or installation procedure to install the OpenVMS Alpha 7.1-1H1 operating system, note the following: 1-1 General Release Notes 1.1 Guidelines for Updating and Installing the OpenVMS Alpha Operating System o DIGITAL recommends that only the new computers (and other new hardware) supported in this release run Version 7.1-1H1 of the OpenVMS operating system. o When using the software installation menu system contained on the operating system CD-ROM, you cannot specify the PRESERVE option to upgrade to Version 7.1-1H1 of the operating system. You must perform either an update or an installation, as outlined in the following sections. o The OpenVMS Version 7.1-1H1 kit should not be used in lieu of remedial kits. ______________________________________________________ The following new hardware is supported with OpenVMS Version 7.1-1H1: o Ultra SCSI - KZPBA-CA single-ended adapter on AlphaServers 4100, 4000, 2100, 2100A, 2000, 1000, 1000A and 800 - KZPSA adapter (minimum version firmware A11) with HSZ70 controller in the Enterprise Storage Array 10,000 and 7,000 o AlphaServer 800 5/500 o DIGITAL Modular Computing Components (21164a) - Alpha 5/366 PICMG SBC - Alpha 5/433 PICMG SBC o DE500-BA and DE500-FA (runtime support only) network adapters 1.1.1 When to Update You can update directly to Version 7.1-1H1 of the OpenVMS Alpha operating system only if your Alpha computer is running Version 7.1 of the OpenVMS Alpha operating system. When deciding whether to update your system, note the following: o The update procedure does not initialize the system disk; it leaves layered products and user files intact. 1-2 General Release Notes 1.1 Guidelines for Updating and Installing the OpenVMS Alpha Operating System o If your system is running a version of the OpenVMS Alpha operating system prior to Version 7.1, you must upgrade to OpenVMS Alpha Version 7.1 before applying this update (if you do not want to perform a full installation, which would overwrite existing files on your system disk). See the OpenVMS Alpha Version 7.1 Upgrade and Installation Manual for information about the upgrade procedure. o If you are adding a new Alpha computer to an existing cluster, you can update a backup copy of a Version 7.1 system disk (from a system already in that cluster) to create a Version 7.1-1H1 system disk for the new computer. 1.1.2 How to Update To update your system to Version 7.1-1H1 of the OpenVMS Alpha operating system, follow the procedures described in Chapter 2. 1.1.3 When to Install You must perform a full installation (rather than an update) if your system meets one of the following conditions: o Your Alpha computer is new. (However, if you are adding a new Alpha computer to an existing cluster, you can update a backup copy of a Version 7.1 system disk from a system already in that cluster to create a Version 7.1-1H1 system disk for the new computer.) o Your Alpha computer has never had any version of the OpenVMS Alpha operating system running on it. o Your Alpha computer is running the OpenVMS Alpha operating system and you want to erase the contents of the system disk (both Alpha and user files). 1-3 General Release Notes 1.1 Guidelines for Updating and Installing the OpenVMS Alpha Operating System 1.1.4 How to Install To install the OpenVMS Alpha Version 7.1-1H1 operating system, do the following: 1. Review the release notes in this document and accompanying cover letters. 2. Begin the installation using the OpenVMS Alpha Version 7.1 Upgrade and Installation Manual. If you are booting from an InfoServer system, note the following differences: o Enter APB_1H1071 for the ISL file name that you specify on the boot command line. For example: >>> BOOT -FL 0,0 -FI APB_1H1071 EWA0 o Enter ALPHA0711H1, when the ISL program prompts you for the service name. 3. Perform postinstallation procedures described in the OpenVMS Alpha Version 7.1 Upgrade and Installation Manual. 1.2 Remedial Kits OpenVMS continues to make improvements and enhancements to the operating system through remedial kits. Contact your DIGITAL support representative to obtain the most recent remedial kits or monitor the following DIGITAL Internet site: http://www.service.digital.com/html/patch_public.html 1.2.1 Remedial Kits Integrated into Version 7.1-1H1 OpenVMS Version 7.1-1H1 contains the following remedial kits. These improvements and enhancements have been integrated into the operating system. o ALPSCSI01_071 Contains corrections and enhancements for the following SCSI drivers: - DKdriver, MKdriver, PKCdriver, PKEdriver, PKJdriver, PKQdriver, PKSdriver, PKTdriver, and PKZdriver 1-4 General Release Notes 1.2 Remedial Kits o ALPCPU1601_071 Allows the use of mixed EV5 and EV56 CPUs, running the same speed, on AlphaServer 4000 and 4100 systems. o ALPCPUC02_071 Contains changes that allow DECevent to properly identify the failing SIMM on AlphaServer 8200 /8400 systems 4 GB memory module, in the event of a correctable data error (CRD). o ALPCPU101_071 Provides MEMORY CHANNEL support for the following systems: - AlphaServer 1000a 5/266 - AlphaServer 800 5/333 - AlphaServer 800 5/400 - AlphaServer 1000 5/266 1.2.2 Pertinent Remedial Kits That Are Not Integrated into Version 7.1-1H1 Read the following sections for pertinent information on remedial kits that are not included with OpenVMS Version 7.1-1H1 but may be important to your Version 7.1-1H1 work environment. 1.2.2.1 OpenVMS Cluster Compatibility Kits The OpenVMS Cluster Compatibility Kits that shipped with OpenVMS Version 7.1 have been superseded by remedial kits ALPCLUSIO01_062 for Alpha systems and VAXCLUSIO01_062 for VAX systems. These kits are required for OpenVMS Version 6.2 systems that are members of an OpenVMS Cluster system that includes systems running OpenVMS Version 7.1 or OpenVMS Version 7.1-1H1. The kits contain the OpenVMS Version 7.1 enhancements to Volume Shadowing, Mount, lock manager, and other quality improvements for OpenVMS Version 6.2 systems. The kits also contain limited support for SCSI device naming using port allocation classes. 1-5 General Release Notes 1.2 Remedial Kits To obtain these kits, contact your DIGITAL support representative or use the following DIGITAL Internet site: http.//www.service.digital.com/html/patch_public.html 1.2.2.2 Volume Shadowing Remedial Kits If you are using Volume Shadowing on any Version 7.1-1H1 hardware system, DIGITAL recommends that you install the ALPSHAD03_071 (or later) Remedial Kit. If ALPSHAD01 or ALPSHAD02 was installed prior to the OpenVMS Alpha Version 7.1-1H1 installation, the SDA display of shadowing virtual units will be incorrect following the Version 7.1-1H1 installation. ALPSHAD03_071 (and later) contains the updated SDA$SHARE and SYS$BASE_IMAGE images that function correctly with OpenVMS Alpha Version 7.1-1H1 and Volume Shadowing. 1.2.2.3 MEMORY CHANNEL Remedial Kit A MEMORY CHANNEL remedial kit, ALPMC01_071, is available. ALPMC01_071 is recommended for existing MEMORY CHANNEL configurations that are experiencing an abnormally high error rate during reinitialization of MEMORY CHANNEL nodes. This kit also provides support for 8-node MEMORY CHANNEL configurations. (Without this kit, only 4-node MEMORY CHANNEL configurations are supported.) ________________________ Note ________________________ If you choose to install the ALPMC01_071 kit on the nodes in your MEMORY CHANNEL configuration, you must install it on all MEMORY CHANNEL nodes. Furthermore, if the MEMORY CHANNEL nodes are not connected by a second OpenVMS Cluster interconnect, you must shut down your MEMORY CHANNEL cluster and reboot each node. (For more information, see the ALPMC01_071 kit release notes.) ______________________________________________________ Prior to this release, to support MEMORY CHANNEL, another remedial kit, ALPCPU101_071, was required for the following systems: o AlphaServer 1000a 5/266 1-6 General Release Notes 1.2 Remedial Kits o AlphaServer 800 5/333 o AlphaServer 800 5/400 o AlphaServer 1000 5/266 This remedial kit is no longer required. MEMORY CHANNEL support for these systems is integrated into OpenVMS Alpha Version 7.1-1H1. 1.2.2.4 Remedial Kit for Alpha Systems with More than 4 GB Memory or with User-Written SCS System Applications A remedial kit exists for two problems detected on Alpha systems. One problem pertains to the failure of certain adapters to initialize. The other pertains to a potential, but rare, data corruption problem with user-written SCS system applications. Although the problems are different, the solutions to both are similar and are contained in the same remedial kit- ALPDRIV04_71. Adapter Initialization Problem An adapter initialization problem exists for OpenVMS Alpha systems with memory greater than 4 gigabytes and the following adapters: o CIPCA (CI-to-PCI), CIXCD (CI-to-XMI), or KFMSB (DSSI-to-XMI) adapters Potential Data Corruption Problem with User-Written SCS System Applications A potential data corruption problem exists for OpenVMS Alpha systems using the following software and adapters: o User-written SCS system applications with buffer offsets greater than 8K-1 bytes. The use of buffer offsets of this size is unsupported and extremely unlikely. o CIPCA (CI-to-PCI), CIXCD (CI-to-XMI), or KFMSB (DSSI-to-XMI) adapters. The ALPDRIV04_71 Remedial Kit is not included in Version 7.1-1H1. Therefore, DIGITAL recommends that you contact your DIGITAL support representative to obtain this kit if your system configuration matches either of the previous descriptions. 1-7 General Release Notes 1.3 Ultra SCSI Support 1.3 Ultra SCSI Support Ultra SCSI was invented by DIGITAL and subsequently standardized by the ANSI SCSI committee. Ultra SCSI incorporates several improvements over its predecessor, Fast SCSI, including an increase in the maximum transfer rate on the SCSI bus from 10 MHz to 20 MHz. For a wide Ultra SCSI bus, this means an increase in maximum bus bandwidth from 20 MB/sec. to 40 MB/sec. The OpenVMS SCSI device drivers in Version 7.1-1H1 support Ultra SCSI operations on devices that are capable of operating in that mode. For information on which SCSI devices support Ultra SCSI and how to configure them, see StorageWorks UltraSCSI Configuration Guidelines (order number EK-ULTRA-CG). OpenVMS Alpha Version 7.1-1H1 currently supports the following Ultra SCSI devices in Ultra SCSI mode: o Single-ended Ultra SCSI host adapter, KZPBA-CA The KZPBA-CA adapter is supported on AlphaServer 4100 systems and smaller AlphaServer systems. This adapter can be used with Ultra SCSI storage devices (except the HSZ70) and non-Ultra SCSI storage devices in single host configurations. o KZPAC Ultra SCSI host RAID controller Support for differential Ultra SCSI host adapters, including support for multihost configurations and the HSZ70, is planned for the near future. For the latest information about Ultra SCSI support, consult your DIGITAL service representative. The HSZ70 can be used now in a multihost KZPSA configuration at non-Ultra SCSI speeds. When the KZPSA is used with the HSZ70, the KZPSA requires firmware version A11 or greater. Multihost KZPSA, KZTSA, and KZPAA configurations continue to be supported in OpenVMS Alpha Version 7.1-1H1. Refer to Guidelines for OpenVMS Cluster Configurations for additional information about the operation of multihost SCSI buses in OpenVMS Cluster systems. 1-8 General Release Notes 1.3 Ultra SCSI Support 1.3.1 Coexistence of Ultra SCSI Devices With Other SCSI Devices Ultra SCSI devices can be used on the same SCSI bus as non- Ultra SCSI devices. For example, Ultra SCSI peripherals such as the RZ1DB-VW can be used at non-Ultra speeds with the KZPSA adapter. Furthermore, non-Ultra SCSI peripherals such as the RZ29B can be used with the KZPBA Ultra SCSI host adapter. 1.4 SCSI Device Naming Using Port Allocation Classes The following notes pertain to restrictions and potential problems when using port allocation classes to name SCSI devices. 1.4.1 SCSI Device Naming Advisory DIGITAL requires a configuration correction for all OpenVMS Alpha Version 7.1 and 7.1-1H1 systems that are using the SCSI device naming feature. New in OpenVMS Alpha Version 7.1, this feature introduced SCSI port allocation classes to facilitate the use of shared SCSI buses in an OpenVMS Cluster system. When the new SCSI device naming feature is enabled, the SCSI port with the OpenVMS device name PKA must have a defined port allocation class of 0, or a positive integer. This is required in all cases, regardless of whether PKA is connected to a shared (multihost) bus or a private bus. Failure to set a port allocation class for PKA, or setting it to -1, can cause some I/O operations to be issued to the wrong SCSI device, causing data corruption or loss. This requirement is not currently enforced by OpenVMS Alpha Version 7.1 and Version 7.1-1H1 software. Therefore, you must make sure that your systems adhere to it. You can use the following procedure to check for compliance with this requirement. You should perform this check on each OpenVMS Alpha Version 7.1-1H1 system in your OpenVMS Cluster system. 1. Enter the following command to determine if the new SCSI device naming feature is enabled: $ WRITE SYS$OUTPUT F$GETSYI("DEVICE_NAMING") 1-9 General Release Notes 1.4 SCSI Device Naming Using Port Allocation Classes If the value displayed is 0, the new SCSI device naming feature is not enabled on this node, and the node does not require any further checking. If the value displayed is 1, the new SCSI device naming feature is enabled on this node, and you must proceed to step 2. 2. Check the SCSI port allocation class definitions in the SYS$SYSTEM:SYS$DEVICES.DAT file. The SYS$DEVICES.DAT file is an ASCII text file that can be typed, searched, or examined with a text editor. Note that this file usually resides in SYS$COMMON:[SYSEXE] and can be shared by multiple nodes in an OpenVMS Cluster system. Therefore, entries in this file are usually in the following node-specific format: [Port $PKA] Allocation Class = Also, if there are multiple entries for a specific $PKA port, only the last one applies. The following command can be used to scan for the port allocation class specified for the PKA bus and will find all instances, including duplicates: $ SEARCH SYS$SYSTEM:SYS$DEVICES.DAT/MATCH=AND/WINDOW=(0,2) PORT,PKA You can use the output of this command to verify that a port allocation class of 0 or a positive integer value has been specified for the PKA device for each node that uses this SYS$DEVICES.DAT file. SCSI port allocation classes can be set or changed using the SYS$MANAGER:CLUSTER_CONFIG.COM command procedure. For information about setting port allocation classes, see Section 6.2.15 in the OpenVMS Cluster Systems manual. For more information about using or changing SCSI port allocation classes, see Section 3.11.8 in the OpenVMS Version 7.1 New Features Manual and Section 6.2 in the OpenVMS Cluster Systems manual. DIGITAL would also like to clarify and emphasize the requirements for using the new SCSI device naming feature in a mixed-version OpenVMS Cluster system. 1-10 General Release Notes 1.4 SCSI Device Naming Using Port Allocation Classes The new SCSI device naming feature must not be used in a mixed-version OpenVMS Cluster system unless all nodes in the cluster are running: o OpenVMS Version 7.1 o OpenVMS Version 7.1-1H1 o OpenVMS Version 6.2-xxx with the newer OpenVMS Cluster Compatibility Kits (see Section 1.2.2.1 in these Release Notes) For example, this means that the new SCSI device naming feature must not be used in a mixed-version OpenVMS Cluster system that includes a system running OpenVMS Version 7.0. Failure to follow this configuration requirement can cause some I/O operations to be issued to the wrong served SCSI device, causing data corruption or loss. 1.4.2 Possible Problem with SCSI Device Naming and Quorum Disks An OpenVMS system that is booting and attempting to form a new OpenVMS cluster might not be able to do so under all of the following conditions: o The node requires the votes from a quorum disk to form a new cluster. o The node is using the SCSI port allocation class device naming method and has a SCSI port with a positive port allocation class value. o The quorum disk is not the system disk. Under these conditions, the booting system might hang shortly after displaying the following message on the system console terminal: %SYSINIT-I- waiting to form or join an OpenVMS Cluster DIGITAL recommends that you not use SCSI port allocation classes if you need to rely on a quorum disk, unless you can designate the system disk as the quorum disk. DIGITAL expects to remove this restriction in a future release. 1-11 General Release Notes 1.4 SCSI Device Naming Using Port Allocation Classes 1.4.3 SCSI Shared Interconnect Requires Same Node Allocation Class Nodes on a shared SCSI interconnect, regardless of whether they also use port allocation classes, must use the same nonzero node allocation class. Prior to the introduction of port allocation classes in OpenVMS Version 7.1, nodes sharing a SCSI interconnect were required to use the same nonzero node allocation class. When port allocation classes were introduced in OpenVMS Version 7.1, this requirement was mistakenly removed from Guidelines for OpenVMS Cluster Configurations, Table A-1. 1.4.4 SCSI Device Naming Conflict That Prevents Satellite Booting A satellite system that is using SCSI port allocation classes for its directly attached SCSI ports can not successfully boot into an OpenVMS Cluster system under the following conditions: o The satellite system is booting from an MSCP-served SCSI disk o SCSI port allocation classes are enabled on the satellite system, that is, system parameter DEVICE_ NAMING=1 o The SYS$DEVICES.DAT file on the satellite system defines a non-negative port allocation class for its PK port that has the same controller letter in its name as the MSCP-served system disk for the satellite For example, these conditions are met if a satellite system is booting from an MSCP-served system disk that is named $100$DKB100 and its PKB port has a port allocation class of 20. When these conditions are met, the satellite system will display the following message on the console and fail to make any further progress: %VMScluster-I-RETRY, Attempting to reconnect to a system disk server To avoid this problem, do not boot from an MSCP-served system disk whose controller letter matches that of any local SCSI port. DIGITAL plans to fix this problem in a future release. 1-12 General Release Notes 1.5 Incorrect Default Value of the MSCP_CMD_TMO System Parameter 1.5 Incorrect Default Value of the MSCP_CMD_TMO System Parameter The Version 7.1 default value for the MSCP_CMD_TMO system parameter is inappropriately set at 600. DIGITAL recommends that you set this value to zero. The parameter unit is also incorrectly described by the System Generation Utility as being in CNTLRTMOs (controller timeouts) instead of seconds. MSCP_CMD_TMO is the time in seconds that the OpenVMS MSCP server uses to detect MSCP command timeouts. The MSCP Server must complete the command within a built-in time of approximately 40 seconds plus the value of the MSCP_CMD_TMO parameter. An MSCP_CMD_TMO value of zero is normally adequate. A value of zero provides the same behavior as in previous releases of OpenVMS (which did not have an MSCP_CMD_TMO system parameter). A nonzero setting increases the amount of time before an MSCP command times out. If command timeout errors are being logged on client nodes, setting the parameter to a nonzero value on OpenVMS servers reduces the number of errors logged. Increasing the value of this parameter reduces the number of client MSCP command timeouts and increases the time it takes to detect faulty devices. If you need to decrease the number of command timeout errors, DIGITAL recommends you set an initial value of 60. If timeout errors continue to be logged, you can increase this value in increments of 20 seconds. MSCP_CMD_TMO is a dynamic parameter. 1.6 Multiprocessor Systems with CIPCAs: SMP_SPINWAIT Restriction If your system uses a CIPCA adapter and you operate with MULTIPROCESSING set to a nonzero value, you must reset the value of the SMP_SPINWAIT parameter to 300000 (3 seconds) instead of the default 100000 (1 second). If you do not change the value of SMP_SPINWAIT, a CIPCA adapter error could generate a CPUSPINWAIT system bugcheck similar to the following: 1-13 General Release Notes 1.6 Multiprocessor Systems with CIPCAs: SMP_SPINWAIT Restriction **** OpenVMS (TM) Alpha Operating System V7.1-1H1 - BUGCHECK **** ** Code=0000078C: CPUSPINWAIT, CPU spinwait timer expired This restriction will be removed in a future OpenVMS release. ________________________ Note ________________________ This release note supersedes a similar release note, note 4.15.2.4.5, in OpenVMS Version 7.1 Release Notes, which also included a SYSTEM_CHECK parameter restriction. The SYSTEM_CHECK parameter restriction is incorrect. Furthermore, the earlier release note stated that the change to the SMP_SPINWAIT parameter was required for a MULTIPROCESSING parameter setting of 1 or 2. This requirement applies to all nonzero MULTIPROCESSING parameter settings. ______________________________________________________ 1.7 Updating the SRM Console on Digital Modular Computing Components (DMCC) To update the SRM console on the Alpha 4/233 (21064a), 4/266 (21164a), 5/366, and 5/433 DMCC systems, you must choose either the SRM console or the AlphaBIOS setup. You can store only one console. o If you are running OpenVMS on the these systems, update the SRM console only o If you are running Windows NT on the these systems, update the AlphaBIOS setup only However, if you accidentally update both the SRM and the AlphaBIOS consoles, you will enter the AlphaBIOS Setup menu, and you will not have the option to return to the SRM console. The only way to then exit the AlphaBIOS Setup menu and return to the SRM console, is to use a Firmware Update Utility located at the following DIGITAL Internet site: ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html 1-14 General Release Notes 1.8 After Upgrading or Installing OpenVMS Version 7.1-1H1 1.8 After Upgrading or Installing OpenVMS Version 7.1-1H1 A problem may occur if you attempt to remove DECnet-Plus (DECNET_OSI), DECwindows Motif (DWMOTIF), or DIGITAL TCP/IP Services for OpenVMS (UCX) after you upgrade to OpenVMS Version 7.1-1H1. If you use the PRODUCT REMOVE command to remove DECnet-Plus, DECwindows Motif, or DIGITAL TCP/IP Services for OpenVMS, the POLYCENTER Software Installation Utility may return an error message. For example, if you attempt to remove DECnet-Plus (DECNET_OSI) the following error message may occur: %PCSI-E-REFUNA, product DEC AXPVMS DECNET_OSI V7.1 referenced by DEC AXPVMS OPENVMS J7.1-1H1 is unavailable Terminating is strongly recommended. Do you want to terminate? [YES] In this example, the DECnet-Plus (DECNET_OSI) product will successfully be removed, however, the OPENVMS product suite will continue to be configured with DECnet-Plus (DECNET_OSI) as a selected option. To avoid this problem, follow these steps to remove a layered product and to reconfigure the OPENVMS product suite: 1. Enter a PRODUCT SHOW PRODUCT/FULL command to list all installed products and to determine which products (if any) are referenced by the OPENVMS product suite. 2. If the DECNET_OSI, DWMOTIF, or UCX products are referenced by the OPENVMS product suite, mount the OpenVMS Alpha Version 7.1-1H1 CD-ROM and enter the following commands: $ DEFINE PATH cdrom:[VMS$COMMON],cdrom:[KITS.*] $ PRODUCT RECONFIGURE OPENVMS /SOURCE=PATH: where: cdrom is the device name where the distribution CD-ROM is mounted. 3. Enter NO to the "defaults for all options" question. Do you want the defaults for all options? [YES] 1-15 General Release Notes 1.8 After Upgrading or Installing OpenVMS Version 7.1-1H1 4. Options for the OPENVMS product suite will be displayed. Press Return to accept the default values for the options, or enter NO to change an option. For example, enter NO to remove DECnet-Plus for OpenVMS Alpha (DECNET_OSI): DECnet-Plus for OpenVMS Alpha [YES] Before the removal of a product, you will be asked to confirm the action. ________________________ Note ________________________ You can use the PRODUCT REMOVE command if you install DECnet-Plus (DECNET-OSI), DECwindows Motif, or DIGITAL TCP/IP Services for OpenVMS (UCX) with the PRODUCT INSTALL command after upgrading or installing OpenVMS 7.1-1H1. In this case the layered product will not be referenced by the OPENVMS product suite. ______________________________________________________ 1.9 Field Replaceable Units (FRU) Table Error on AlphaServer 8200/8400 and 4100 Systems The size of the buffer allocated by the default value of the SYSGEN parameter ERLBUFFERPAGES is limited to 32 pagelets. If the the Field Replaceable Unit (FRU) table exceeds this limit during a boot of the OpenVMS Alpha operating system on an AlphaServer 8200/8400 or 4100 system, an entry will not be written to the error log file. 1.10 DECevent The following sections contain release notes that pertain to DECevent. 1.10.1 DECevent 2.5-2 Kit DECevent 2.5-2 is included on the OpenVMS Alpha Version 7.1-1H1 CD-ROM in the [DECEVENT_0252.KIT] directory. Although the installation messages state DECEVENT025H and the DECevent banner states DECevent Version 2.5A, this 2.5-2 kit is the most current and up-to-date kit. 1-16 General Release Notes 1.10 DECevent 1.10.2 Change to DECevent DIAGNOSE Command Installation In OpenVMS Alpha Version 7.0 and earlier releases of OpenVMS Alpha, the DECevent DCL command DIAGNOSE was defined during the operating system installation or upgrade. When you install OpenVMS Alpha Version 7.1-1H1, the DIAGNOSE command is disabled. In order to enable the DIAGNOSE command, you must install the DECevent kit provided on the OpenVMS Alpha Version 7.1-1H1 CD-ROM following the installation of OpenVMS Alpha Version 7.1-1H1. The DECevent kit is located in the directory [DECEVENT_0252.KIT] on the Alpha CD-ROM. If the DECevent kit provided on the OpenVMS Alpha CD-ROM is not installed after the operating system, users attempting to use the DIAGNOSE command will receive the following system message: $ DIAGNOSE [params] %DIA-E-NOINSTAL, DIAGNOSE has not been installed on this system 1.10.3 AlphaServer 8200/8400 Systems and DECevent DIGITAL recommends that you install DECevent Version 2.5 software with AlphaServer 8200/8400 systems. This version of DECevent has been modified and supports changes that allow DECevent to properly diagnose correctable read errors that occur on the AlphaServer 8200/8400 systems 4 GB memory modules. DECevent is located in the following directory on the OpenVMS Version 7.1-1H1 CD-ROM: [DECEVENT_0252.KIT] 1.11 XDELTA Problem with Newer OpenVMS Systems If your system was introduced with OpenVMS Version 6.2 or later, you might not be able to use XDELTA. Typical symptoms of this XDELTA problem are an ACCVIO error or a system crash with a Kernel stack not valid message. A workaround is available, so that you can use XDELTA without experiencing this problem. 1-17 General Release Notes 1.11 XDELTA Problem with Newer OpenVMS Systems To determine if your system might be prone to this problem, you can run the System Dump Analyzer (SDA) Utility, as shown in the following example: $ ANALYZE/SYSTEM OpenVMS (TM) Alpha system analyzer SDA> EXAMINE EXE$GQ_CPUTYPE EXE$GQ_CPUTYPE: 00000000.00000005 "........" If the CPU type of your system is 5, as shown in this example, use the following workaround: 1. Do a conversational bootstrap. The SYSBOOT> prompt will be displayed. 2. At the SYSBOOT> prompt, enter the following command: SYSBOOT> SET LOAD_SYS_IMAGES 3 This command causes XDELTA to start correctly. When you are finished using XDELTA, do another conversational bootstrap. At the SYSBOOT> prompt, enter the following command: SYSBOOT> SET LOAD_SYS_IMAGES 7 This problem will be corrected in OpenVMS Version 7.2. 1.12 MSCP-Served RRD45 CD-ROM Testing UETP does not support MSCP-served RRD45 CD-ROMs on OpenVMS Alpha. This release note describes a temporary workaround that you can use until support is added in a future release. 1-18 General Release Notes 1.12 MSCP-Served RRD45 CD-ROM Testing If you have an MSCP-served RRD45 CD-ROM, UETP will fail in the following manner: %UETP-S-BEGIN, UETINIT01 beginning at 13-NOV-1995 16:35:22.76 . . ********************** * DISK_NODE$DKA * * Error count = 1 * ********************** -UETP-E-TEXT, RMS file error in file NODE$DKA500:NODE_NODE$DKA5000.TST -RMS-E-DNR, device not ready, not mounted, or unavailable %UETP-S-ENDED, UETDISK00 ended at 13-NOV-1995 16:36:15.10 . . NODE$DKA: testable 100, 200, 300 untestable 500 . . *************************************************** * * END OF UETP PASS 1 AT 13-NOV-1995 16:44:49.85 * * *************************************************** You can work around this problem and test the MSCP-served RRD45 device by running the CD-ROM test (UETCDRO00.EXE) against the MSCP-served RRD45 separately from UETP.COM. Follow these steps: 1. Edit UETSUPDEV.DAT to include the following line: 01 36 UETCDRO00.EXE ! RRD45 2. Edit UETINIDEV.DAT to change the "N" in the row for the MSCP-served RRD45 device to a capital "T". The line should look like this (the number might be different): UCB T 00500 UETCDRO00.EXE 3. Run the CD-ROM test, for example: $ RUN UETCDRO00.EXE Controller designation?: NODE$DKA %UETP-S-BEGIN, UETCDRO00 beginning at 13-NOV-1995 15:15:43.20 %UETP-I-ABORTC, CDRO_NODE$DKA to abort this test, type ^C %UETP-S-ENDED, UETCDRO00 ended at 13-NOV-1995 15:18:45.98 $ 1-19 General Release Notes 1.13 Year 2000 DIGITAL Product Warranty 1.13 Year 2000 DIGITAL Product Warranty DIGITAL stands behind the Year 2000 readiness of its products with its Year 2000 DIGITAL Product Warranty. If you want DIGITAL Year 2000 warranty coverage for DIGITAL OpenVMS Version 7.1-1H1, you must apply the OpenVMS Year 2000 remedial kit that is being released this fall for OpenVMS Version 7.1. That kit will include fixes to a very few, minor problems that our code investigation uncovered in some older and rarely used components. OpenVMS Version 7.1 has been tested for the Year 2000, including simulations of the transition to the Year 2000 and beyond, and no other problems have been found. For the latest information on the status of DIGITAL OpenVMS and its layered products, including updates on any problems found, check the OpenVMS Year 2000 web site: www.openvms.digital.com/openvms/products/year-2000/index.html This site includes a link to the full description of the Year 2000 DIGITAL Product Warranty, or you can access that information directly at this URL: www.software.digital.com/year2000/y2k_isa2.htm 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha The Extensible Simple Network Management Protocol (eSNMP) makes it possible for network managers to manage many different types of devices across all network and vendor boundaries through the use of databases called MIBs (Management Information Bases). Essentially, information is exchanged between master agents and subagents, which are devices such as routers and servers on the network being managed, and managers, which are the devices on the network through which the management is done. The DIGITAL Server MIB (DSM) consists of two extensions, or subagents: o System - Describes a management interface to Alpha system information not defined by standard MIBs. 1-20 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha o Management - Describes instrumentation in the DIGITAL extension agent, including the ability to detect and monitor thresholds on integer variables. The representation of the DSM within the standard Structure of Managed Information (SMI) framework is: iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) 36 OpenVMS Alpha Version 7.1-1H1 implements the DSM subagents on the AlphaServer 800, 1000, 4000, 4100, 8200, and 8400 systems. With the DSM subagents, customers can remotely determine and manage important information such as: o Firmware revision numbers o Base system descriptions o FRU (field replaceable unit) information and descriptions o Processor and cache status o Interface configurations o Environmental conditions in the system enclosure that might be detrimental to the hardware To access the DSM subagents, you use the following software: o DIGITAL's ServerWORKS Manager Version 3.0 or any MIB browser that has access to the DSM definitions. o DIGITAL TCP/IP Services for OpenVMS Version 4.1 (UCX). The DSM subagents use the SNMP agent supplied with UCX to communicate with SNMP clients. The following sections describe the DSM subagents and explain how to set up your system to use them. 1.14.1 Overview of DSM Subagents DSM subagents respond to SNMP requests for a DSM object - the data item that the network manager is concerned with, or a trap - information about a change of status. A subagent is responsible for reporting on and maintaining the data pertaining to these objects and traps. 1-21 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha The DSM System subagent implements the objects listed in Table 1-1. Each object corresponds to a group of base system and environmental information relevant to OpenVMS Alpha networking and can be accessed by a network manager through ServerWORKS Manager. ___________________________________________________________________ Table 1-1 DSM System Subagent Objects Implemented on OpenVMS Alpha Object Data Type Access Description ___________________________________________________________________ MIB Information Group ___________________________________________________________________ svrSysMibMajorRev Integer Read only The major revision number of this implementation of the svrSystem MIB. Currently 1. svrSysMibMinorRev Integer Read only The minor revision number of this implementation of the svrSystem MIB. Currently 0. (continued on next page) 1-22 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Base System Description Group ___________________________________________________________________ svrSystemModel DisplayString Read only System and model name. For example, AlphaServer 2100. svrSystemDescr DisplayString Read only General text description of system type. (continued on next page) 1-23 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Base System Description Group ___________________________________________________________________ svrSystemBoardFruIndex Integer Read only The index of the Field Replaceable Unit (FRU) in the FRU table describing the serial number and other asset information of the board. If unknown, 0. svrSystemBootedOS Integer Read only The current booted operating system. svrSystemShutdownReason DisplayString Read only The possible reason for the system shutdown. svrFirmwareIndex Integer Read only An index value unique to the local system. (continued on next page) 1-24 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Base System Description Group ___________________________________________________________________ svrFirmwareDescr DisplayString Read only Descriptive text for items such as the SRM console, ARC console, and system BIOS. svrFirmwareRev DisplayString Read only A version number, often of the form Vx.y or Vx.y-z. svrFwSymbolName DisplayString Read only The symbol name as visible on the console. svrFwSymbolValue Octet string Read only The symbol value. Null if none or unknown. (continued on next page) 1-25 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ System Processor Group ___________________________________________________________________ svrCpuIndex Integer Read only An index value for the CPU entry that is unique to the local system. svrCpuManufacturer DisplayString Read only The manufacturer of the processor. (continued on next page) 1-26 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ System Processor Group ___________________________________________________________________ svrCpuRevision DisplayString Read only Version information in processor- specific format. svrCpuFruIndex Integer Read only The index of the FRU entry in the FRU table that describes the asset information of the component containing the processor. If unknown, 0. svrCpuCacheIndex Integer Read only The local index value. svrCpuCacheLevel Integer Read only Level 1, level 2, level 3 cache, other, or unknown. (continued on next page) 1-27 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ System Processor Group ___________________________________________________________________ svrCpuCacheType Integer Read only Type of cache: internal, external, internal instruction, or internal data. svrCpuCacheSize Kbytes Read only Cache size in Kbytes. svrCpuCacheSpeed Integer Read only Cache speed in nanoseconds. If unknown, 0. svrCpuCacheStatus Integer Read only Current status of the cache: enabled, disabled, other, or unknown. (continued on next page) 1-28 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Memory Configuration Group ___________________________________________________________________ svrPhysicalMemorySize Kbytes Read only Total amount of physical memory as seen by the operating system. svrPhysicalMemoryFree Kbytes Read only Amount of free physical memory. svrMemIndex Integer Read only Unique index for this entry. (continued on next page) 1-29 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Memory Configuration Group ___________________________________________________________________ svrMemSize Kbytes Read only Length of memory range. svrMemFruIndex Integer Read only Index of the FRU entry in the FRU table on which the memory resides. If unknown, 0. svrBusIndex Integer Read only An index value that is unique to the local system. svrBusType BusTypes Read only Bus type. svrLogicalSlotNumber Integer Read only Unique logical slot number on a given bus. svrLogicalSlotDescr DisplayString Read only Device description derived from ID or as set by the management station. svrLogicalSlotRevision DisplayString Read only Vendor- supplied major and minor revision of device in the slot. (continued on next page) 1-30 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Physical Configuration Group ___________________________________________________________________ svrFruIndex Integer Read only An index value that is unique to the system. svrFruType Integer Read only General category of FRU type. svrFruDescr DisplayString Read only Detailed description of the FRU type, if known. svrFruVendor DisplayString Read only Manufacturer's name or ID. svrFruPartNumber DisplayString Read only Order number for this unit. svrFruRevision DisplayString Read only Version number of the unit. If an illustration is available, it appears as "Artwork: XXX" following the FRU version number. svrFruFirmwareRevision DisplayString Read only Revision of the firmware, if applicable. Otherwise, null. svrFruSerialNumber DisplayString Read only Unit's serial number. (continued on next page) 1-31 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Environment Group: Thermal ___________________________________________________________________ svrThermalSensorCount Integer Read only Number of thermal sensors present and readable in the system. svrThSensorIndex Integer Read only An index value unique to the local system. svrThSensorReading Integer Read only Current value read by the sensor in units as described by the svrThSensor- ReadingUnits object. svrThSensorReadingUnits ThermUnits Read only Value of sensor in degrees Fahrenheit, Celsius, or relative value. If not available, value will be unknown. svrThSensorStatus Integer Read only The sensor's status value. (continued on next page) 1-32 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ___________________________________________________________________ Table 1-1 (Cont.) DSM System Subagent Objects Implemented on OpenVMS Alpha ___________________________________________________________________ Object Data Type Access Description ___________________________________________________________________ Environment Group: Cooling ___________________________________________________________________ svrFanCount Integer Read only The number of fans whose states are detectable. svrFanIndex Integer Read only An index value unique to the local system. svrFanStatus Integer Read only Current fan status. _________________________________________________________________ Environment Group: Power Supply _________________________________________________________________ svrPowerSupplyCount Integer Read only Number of detectable power supplies reflected as entries in the svrPow- erSupplyTable object. svrPowerSupplyIndex Integer Read only An index value unique to the local system. svrPowerSupplyStatus Integer Read only Current state of the power supply. _________________________________________________________________ 1-33 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha The DSM Management subagent implements the objects and traps listed in Tables 1-2 and 1-3, respectively. Each object or trap corresponds to a group of management areas relevant to OpenVMS Alpha networking and can be accessed by a network manager through ServerWORKS Manager. ______________________________________________________________________ Table 1-2 DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ MIB Information Group ______________________________________________________________________ svrMgtMibMajorRev Integer. Read only. The major revision number of this implementation of the svrMgt MIB. Currently 1. svrMgtMibMinorRev Integer. Read only. The minor revision number of this implementation of the svrMgt MIB. Currently 0. _________________________________________________________________ Alarms Group _________________________________________________________________ svrAlarmNextThrIndex Integer. Read only. The next available index for creating a svrThrEntry object. If the value is -1, the maximum number of thresholds has been reached. A threshold record cannot be created until you delete the current threshold record. svrAlarmEnableTraps Boolean. Read/write. If true, a trap is sent for each triggered alarm. (continued on next page) 1-34 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThresholdTable Sequence of SvrThresholdEntry. Not accessible. The threshold table that describes conditions for setting and resetting alarms. The agent checks this table for exceptions. You can set alarms on absolute values (such as the current integer value of the sampled variable) or on delta values (such as the difference between the current or last value). Alarms can be Greater Than exception alarms, Less Than exception alarms, Equals To alarms, and so on (see the svrThrAlarmType object description). Hysteresis (the tendency of certain binary devices to show different threshold values when changing from 0 to 1 than when changing from 1 to 0) is introduced by providing thresholds both for setting and resetting of the alarm state, thereby limiting the number of traps that are sent on alarm triggering. You can create alarms to persist across agent reboots; however, this is not recommended for dynamic table variables. The triggering of an alarm changes a state variable in the conceptual row and can also trigger the sending of a trap, or the local logging of an event. (continued on next page) 1-35 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThresholdEntry SvrThresholdEntry. Not accessible. A threshold alarm set on an integer variable. An alarm entry is created by the management console using the current value of svrAlarmNextThrIndex to name the instances of the row variables, setting the svrThrStatus to underCreation. When you create a threshold entry for the first time, issue a set request on svrThrStatus. You can set the remaining row variables in the same operation or in subsequent operations. Those not set retain their default values as described. You must set variable values for the following objects in the Alarms group before you enable the alarm: o svrThrStatus (set to underCreation) o svrThrVariableName through svrThrSeverity (set appropriately; see the object descriptions) (continued on next page) 1-36 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThrIndex Integer. Read only. An index value unique to the local system. On creation, set to the value of svrAlarmNextThrIndex. svrThrStatus Integer. Read/write. Describes the status of the row. When the row is created with the initial set, you must set svrThrStatus to underCreation. When the management console has completed the row setup, it sets this variable to rowEnabled. Variables in the row can only be written if svrThrStatus is in the initial underCreation state or has been set to rowDisabled. To delete the row, set the status to rowInvalid. Be aware that errors in variable polling and threshold checking that cannot be corrected cause a row status change to rowError. Once the status is set to rowError by the agent, the agent does not reset the status. Instead, the management console must reset the status based on information returned with svrThrErrorValue or for other reasons. (continued on next page) 1-37 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThrVariableName Object identifier. Read/write. The object identifier (OID) of an integer variable to be tested against the threshold. At row creation, the variable equals the value 0.0 and must be set to the OID of an integer variable before enabling the alarm. svrThrValueType Integer. Read/write. Absolute or delta value. The default on row creation is absoluteValue. The deltaValue is calculated by taking the current value and subtracting the svtThrLastValue value. svrThrAlarmType Integer. Read/write. An alarm that signals a threshold whose value is Greater Than, Greater Than or Equal To, Equal To, Less Than or Equal To, or Less Than. The default value on row creation is Greater Than. (continued on next page) 1-38 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThrAlarmType (Cont.) Integer. Read/write. Greater Than or Greater Than or Equal To thresholds for absolute values occur when the sample value equals or exceeds the svrThrThresholdValue and svrThrAlarmState was reset. This condition causes svrThrAlarmState to be set and, if svrAlarmEnableTraps is true, a svrThrExceptTrap is sent. SvrThrAlarmState is reset when the sample value falls below or equals svrThrResetValue. Less Than or Less Than or Equal To thresholds for absolute values occur when the sample value falls below or equals the svrThrThresholdValue, and svrThrAlarmState was reset. This condition causes the svrThrAlarmState to be set and, if svrAlarmEnableTraps is true, a svrThrExceptTrap is sent. SvrThrAlarmState is reset when the sample value exceeds or equals svrThrResetValue. Equal To thresholds for absolute values occur when the sample value equals svrThrThresholdValue and svrThrAlarmState was reset. This condition causes the svrThrAlarmState to be set and, if svrAlarmEnableTraps is true, a svrThrExceptTrap is sent SvrThrAlarmState is reset when the sample value does not equal svrThrResetValue. The same conditions apply for delta values as for absolute values except the difference between the sample value and the svrThrLastValue is used for comparison with both the svrThrThresholdValue and the svrThrResetValue. Note that it is possible to have negative delta values since the difference is computed as the current value minus the svrThrLastValue. (continued on next page) 1-39 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThrSampleInterval Integer. Read/write. The interval (in seconds) between polls to check for threshold exceptions. The default value on row creation is 30 seconds. Minimum value: 1. svrThrPersistent Boolean. Read/write. If true, the threshold persists across agent restarts. Default on row creation: false. By default, the files used to store persistent data are SYS$SYSTEM:UCX$MGT_THRESHOLDS.DAT and SYS$SYSTEM:UCX$MGT_ THRESHOLDS.BAK. To move the files off the system disk or rename them, the system manager can define the logical names UCX$MGT_PERSISTENCE_DAT and UCX$MGT_PERSISTENCE_BAK in the SYS$MANAGER:SYLOGICALS.COM file as appropriate. For example, to point to files in a different location, add the following definitions to SYS$MANAGER:SYLOGICALS.COM: $ DEFINE/SYS UCX$MGT_PERSISTENCE_DAT DISK2:[SNMP.MIB]PERSIST.DAT; $ DEFINE/SYS UCX$MGT_PERSISTENCE_BAK DISK2:[SNMP.MIB]PERSIST.BAK; (continued on next page) 1-40 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThrThresholdValue Integer. Read/write. The threshold value that is compared to the current or delta value. Default on row creation: 0. svrThrResetValue Integer. Read/write. The value used to reset the threshold on all svrThrAlarmTypes objects except those that are equal to. Default on row creation: 0. svrThrLastValue Integer. Read only. The previous sample needed to evaluate if alarm should be triggered or to evaluate delta values for threshold checking. svrThrAlarmState Integer. Read only. Indicates whether the alarm is currently set or reset. Used by polling management applications to determine if a threshold exception state has been detected based on the alarm definition. Has an initial value of reset when the alarm is enabled or the agent is restarted. The value is reset if svrThrStatus changes to rowDisabled or rowInvalid. For guidelines on state changes, see the description for svrThrAlarmType. (continued on next page) 1-41 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThrLogEvent Boolean. Read/write. If true, logs data to the sub- agent process log file. For example, to SYS$SYSDEVICE:[UCX$SNMP]UCX$SVRMGT_ MIB.LOG (see Section 1.14.2). Default value: false. svrThrDescr DisplayString. Read/write. Describes the type of threshold. Set by the management console, not by the agent. svrThrErrorValue SnmpErrors. Read only. The SNMP-defined error status that caused the svrThrStatus value to become equal to rowError. Valid only at that time. svrThrComparisonName Object identifier. Read/write. An object identifier (OID) to a descriptor attribute used with the svrThrPersistent value to verify that the svrThrVariableName instance is correct. Optional. Default: 0.0. On agent restarts, the value is retrieved and compared to the svrThrComparisonValue. If not equal, the OID instancing for svrThrVariableName might be incorrect. If this situation occurs, svrThrStatus is set to rowError and svrThrErrorValue to badValue. (continued on next page) 1-42 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ______________________________________________________________________ Table 1-2 (Cont.) DSM Management Subagent Objects Implemented on OpenVMS Alpha ______________________________________________________________________ Object Data Type/Access/Description ______________________________________________________________________ Alarms Group ______________________________________________________________________ svrThrComparisonValue DisplayString. Read/write. Date value of svrThrComparisonName. Optional. Used when svrThrPersistent is set. The value is compared to the current value on agent restarts. Default: null. svrThrSeverity Severity. Read/write. Indicates the severity of the threshold. Default on row creation: informational. ______________________________________________________________________ _____________________________________________________________________ Table 1-3 DSM Management Subagent Traps Implemented on OpenVMS Alpha _____________________________________________________________________ Trap Variable Description _____________________________________________________________________ Local Server Control Group _____________________________________________________________________ svrThrHighExceptTrap svrThrVariableName A high svrThrValueType severity svrThrThresholdValue trap. The svrThrLastValue value that svrThrDescr caused the alarm to occur is returned in svrThrLast- Value. (continued on next page) 1-43 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha _____________________________________________________________________ Table 1-3 (Cont.) DSM Management Subagent Traps Implemented on OpenVMS Alpha _____________________________________________________________________ Trap Variable Description _____________________________________________________________________ Local Server Control Group _____________________________________________________________________ svrThrMediumExceptTrap svrThrVariableName A medium svrThrValueType severity svrThrThresholdValue trap. The svrThrLastValue value that svrThrDescr caused the alarm to occur is returned in svrThrLast- Value. svrThrLowExceptTrap svrThrVariableName A low svrThrValueType severity svrThrThresholdValue trap. The svrThrLastValue value that svrThrDescr caused the alarm to occur is returned in svrThrLast- Value. svrThrInformationalExceptTrap svrThrVariableName An Informational svrThrValueType severity svrThrThresholdValue trap. The svrThrLastValue value that svrThrDescr caused the alarm to occur is returned in svrThrLast- Value. _____________________________________________________________________ 1.14.2 Setting Up the System to Use the DSM Subagents To configure SNMP on the system and enable the master agent to accept SET commands from SNMP clients, issue the following UCX management command from the UCX> prompt. This operation requires SYSPRV or BYPASS privileges. UCX> SET CONFIGURATION SNMP /FLAGS=SETS 1-44 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha To enable or disable the type of access to your local MIB data, use the following UCX commands, qualifiers, and options: UCX> SET CONFIGURATION SNMP /[NO]COMMUNITY="name" - _UCX> /[NO]ADDRESS=host address /TYPE=[NO]READ,[NO]TRAP,[NO]WRITE For example, the following command configures SNMP, specifies the community name and address, specifies that the agent can accept SET commands from members of the community, and enables the master agent to send trap messages to members of the community. (Note that READ access is assumed when specifying TRAP or WRITE.) UCX> SET CONFIGURATION SNMP /COMMUNITY="public" /ADDRESS=128.45.2.8 - _UCX> /TYPE=TRAP,WRITE To start the DSM subagents, the system or network manager must modify two files that are provided on the DIGITAL TCP/IP Services for OpenVMS product kit, as follows: 1. Add the following commands to the end of the SYS$STARTUP:UCX$SNMP_STARTUP.COM file: $ RUN /DETACHED - /PROCESS_NAME="UCX$SERVER_MIB" - /OUTPUT=SYS$SYSDEVICE:[UCX$SNMP]UCX$SERVER_MIB.LOG - /ERROR=SYS$SYSDEVICE:[UCX$SNMP]UCX$SERVER_MIB.ERR - /UIC=UCX$SNMP - SYS$SYSTEM:SVRSYSTEM_MIB $ RUN /DETACHED - /PROCESS_NAME="UCX$SVRMGT_MIB" - /OUTPUT=SYS$SYSDEVICE:[UCX$SNMP]UCX$SVRMGT_MIB.LOG - /ERROR=SYS$SYSDEVICE:[UCX$SNMP]UCX$SVRMGT_MIB.ERR - /UIC=UCX$SNMP - SYS$SYSTEM:SVRMGT_MIB 2. Modify the SYS$MANAGER:UCX$SNMP_SHUTDOWN.COM file to enable the shutdowns. The following file differences show modifications made to UCX$SNMP_SHUTDOWN.COM;2 to include shutdown of the DSM subagent: 1-45 General Release Notes 1.14 DIGITAL Server MIB Subagents Implemented on OpenVMS Alpha ************ File SYS$COMMON:[SYSMGR]UCX$SNMP_SHUTDOWN.COM;2 52 $ SUBAGT2 := ucx$server_mib 53 $ SUBAGT3 := ucx$svrmgt_mib 54 $ CONTEXT = "" ****** File SYS$COMMON:[SYSMGR]UCX$SNMP_SHUTDOWN.COM;1 53 $ CONTEXT = "" ************ ************ File SYS$COMMON:[SYSMGR]UCX$SNMP_SHUTDOWN.COM;2 59 $ IF (PRCNAM .EQS. AGENT) .OR. - 60 (PRCNAM .EQS. SUBAGT) .OR. - 61 (PRCNAM .EQS. SUBAGT2) .OR. - 62 (PRCNAM .EQS. SUBAGT3) THEN STOP /ID='P1' 63 $ GOTO _LOOP1 ****** File SYS$COMMON:[SYSMGR]UCX$SNMP_SHUTDOWN.COM;1 59 $ IF (PRCNAM .EQS. AGENT) .OR. (PRCNAM .EQS. SUBAGT) THEN STOP /ID='P1' 60 $ GOTO _LOOP1 ************ Number of difference sections found: 2 Number of difference records found: 4 1.15 Environmental Data Restrictions: AlphaServer 8200 and 8400 Systems The power regulators on AlphaServer 8200 systems do not contain sensors for environmental conditions. Therefore, data cannot be reported in the thermal and power supply MIB groups of the DSM System subagent. Although the power regulators on AlphaServer 8400 systems contain environmental sensors, some configurations might not report environmental information correctly to the DSM System subagent. This problem affects the thermal and power supply MIB groups and will be resolved in a future release of the software. 1-46 General Release Notes 1.16 Device IIA0: Now Configured on AlphaServer 4100 Systems 1.16 Device IIA0: Now Configured on AlphaServer 4100 Systems OpenVMS Alpha Version 7.1-1H1 automatically configures device IIA0: on AlphaServer 4100 systems. The IIA0: device, which is controlled by SYS$IIDRIVER.EXE, provides access to fan, temperature, and power supply status information available through the integrated I2C bus. The DIGITAL Server System MIB, described in Section 1.14, provides the status information to the ServerWORKS console. The interface to the device driver is reserved for DIGITAL use only. 1.17 Device OPA1: Now Configured on AlphaServer 8200 and 8400 Systems OpenVMS Alpha Version 7.1-1H1 automatically configures device OPA1: on AlphaServer 8200 and 8400 systems. The OPA1: device, which is controlled by SYS$OPDRIVER.EXE, provides access to temperature and power supply status information available through the integrated H7263 power regulators. The DIGITAL Server System MIB, described in Section 1.14, provides the status information to the ServerWORKS console. The interface to the device driver is reserved for DIGITAL use only. 1-47 2 _________________________________________________________________ Updating to OpenVMS Alpha Version 7.1-1H1 This chapter describes how to prepare your system for an update, how to use the update procedure, and how to perform post-update tasks. ________________________ Note ________________________ Before you update your system, be sure you have reviewed the update and installation guidelines in Chapter 1. ______________________________________________________ 2.1 Preparing Your System Before you install the kit, perform the following steps: 1. Make sure that your system is running OpenVMS Alpha Version 7.1. 2. Make an image backup copy of the system disk. _______________________ Caution _______________________ A system failure at a critical point in the update procedure might corrupt the contents of the system disk. Therefore, it is important that you back up the system disk at this time so that you always have a working copy. For more information about backing up your system disk, see the OpenVMS Alpha Version 7.1 Upgrade and Installation Manual. ______________________________________________________ 3. Prepare the system disk. Make sure that you have at least 55,000 blocks of free space on the system disk for the update. 2-1 Updating to OpenVMS Alpha Version 7.1-1H1 2.1 Preparing Your System 4. If the system is part of an OpenVMS Cluster configuration, shut down any nodes that boot from the system disk you are updating. 5. To make sure that the SYSTEM account has sufficient quotas and limits, use the OpenVMS Authorize utility as follows: a. Enter the following commands: $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> SHOW SYSTEM b. Compare the limits and quotas of the SYSTEM account to the following minimum required values: _____________________________________________________ Quota Name Minimum Values _____________________________________________________ Open file quota (FILLM) 100 Buffered I/O limit 150 (BIOLM) Direct I/O limit (DIOLM) 150 AST limit (ASTLM) 250 Enqueue quota (ENQLM) 2000 Buffered byte quota count 64000 (BYTLM) _____________________________________________________ c. If necessary, adjust the limits and quotas until they are equal to or greater than the required values. You can change each value by entering a command in the following format: UAF> MODIFY SYSTEM/limit=new_value For example: UAF> MODIFY SYSTEM/DIOLM=18 d. Exit the OpenVMS Authorize utility by entering the following command: UAF> EXIT e. If you adjust any of the parameter or quota values of the SYSTEM account, log out and log in again so that the new values take effect. 2-2 Updating to OpenVMS Alpha Version 7.1-1H1 2.1 Preparing Your System 6. Be sure that you are the only user logged into the SYSTEM account by completing the following steps: a. Enter the following command to notify current users that they must log out: $ REPLY/ALL/BELL/SHUTDOWN "Log out for Version 7.1-1H1 update." b. Enter the following command to prevent nonprivileged users from logging in: $ SET LOGINS/INTERACTIVE=0 7. Next, continue as follows: o If you are updating using an InfoServer system, proceed to Section 2.2. o If you are not using an InfoServer system and do not want to shut down the DECnet software on your system, proceed to Section 2.3. o If you want to shut down the DECnet software on your system, enter the following commands and then go to Section 2.3: $ RUN SYS$SYSTEM:NCP NCP> SET EXECUTOR STATE OFF NCP> EXIT o If you want to shut down the DECnet-Plus software on your system, enter the following command and then go to Section 2.3: $ @SYS$STARTUP:NET$SHUTDOWN.COM 2.2 Preparing to Update Using an InfoServer System If you are using an InfoServer system to update your operating system, you must start the InfoServer Client software and make the CD-ROM drive accessible to your system. This section describes these tasks. To start the InfoServer Client software, perform the following steps: 1. Make sure the system parameter SCSNODE is defined on your system, by entering the following commands: 2-3 Updating to OpenVMS Alpha Version 7.1-1H1 2.2 Preparing to Update Using an InfoServer System $ RUN SYS$SYSTEM:SYSMAN SYSMAN> PARAMETERS USE CURRENT SYSMAN> PARAMETERS SHOW SCSNODE If SYSMAN displays a value for SCSNODE, go to step 3. If SYSMAN does not display a value for SCSNODE, enter the following commands, where node is a unique node name up to six characters in length: SYSMAN> PARAMETERS SET SCSNODE node SYSMAN> PARAMETERS WRITE CURRENT SYSMAN> EXIT After you set SCSNODE, you must reboot the system. For more information about booting the system, see the OpenVMS Alpha Version 7.1 Upgrade and Installation Manual. For more information about SCSNODE as it pertains to OpenVMS Cluster batch and print queues, see the OpenVMS DCL Dictionary or OpenVMS Cluster Systems. 2. Start the InfoServer Client software by entering the following command: $ @SYS$STARTUP:ESS$STARTUP CLIENT As the startup procedure executes, it displays the following messages: %LASTCP-I-VERSION, LASTDRIVER X1.5 is stopped %LASTCP-I-ADAINIT, Initializing adapter xxx for LASTDRIVER %LASTCP-I-STARTED, LASTDRIVER X1.5 started on node node To start the InfoServer Client software each time the system boots, add the following line to SYS$MANAGER:SYSTARTUP_VMS.COM: @SYS$STARTUP:ESS$STARTUP CLIENT 3. After you start the InfoServer Client software, you must make the CD-ROM drive accessible to your system by completing the following steps: a. Insert the OpenVMS Alpha distribution CD-ROM in the drive connected to the InfoServer system. 2-4 Updating to OpenVMS Alpha Version 7.1-1H1 2.2 Preparing to Update Using an InfoServer System b. Enter the following commands: $ RUN SYS$SYSTEM:ESS$LADCP LADCP> BIND/CONNECT/SYSTEM ALPHA0711H1 %LADCP-I-BIND, service bound to logical unit DAD$ALPHA0711H1 (_DADn:) LADCP> EXIT Make note of the device name _DADn: because you must specify this device name during the update procedure. 2.3 Matching Update Procedures to System Configurations Different system configurations require slightly different update procedures. The following list indicates the possible system configurations and the section to which you should refer: o OpenVMS Cluster environment: Section 2.3.1 o Mixed-architecture OpenVMS Cluster environment: Section 2.3.1 (Reapply the update only to system disks for OpenVMS Alpha systems running Version 7.1.) o Local area OpenVMS Cluster environment with one boot server and two system disks: Section 2.3.2 o Standalone system: Section 2.4 ________________________ Note ________________________ As you decide how to update your environment, note that DIGITAL recommends that only the new computers (and other new hardware) supported in this release run Version 7.1-1H1 of the OpenVMS operating system.) ______________________________________________________ 2.3.1 Updating OpenVMS Cluster Environments Use the following procedure to update all OpenVMS Cluster environments. After completing this procedure, all the systems in your OpenVMS Cluster environment will be running Version 7.1-1H1 of the OpenVMS Alpha operating system. 1. Make sure that you have prepared your system for the update, as described in Section 2.1. 2-5 Updating to OpenVMS Alpha Version 7.1-1H1 2.3 Matching Update Procedures to System Configurations 2. Log in to the SYSTEM account on a node that uses the system disk you are updating. 3. Shut down all other nodes in the cluster that boot from the system disk. 4. Apply the update according to the instructions in Section 2.4. 5. If your OpenVMS Cluster environment uses several system disks, repeat steps 1 through 4 in this section for each of those system disks. When the update is complete, perform the postinstallation tasks described in Section 2.5. 2.3.2 Updating a Local Area OpenVMS Cluster System with One Boot Server and Two System Disks To update a local area OpenVMS Cluster system with one boot server and two system disks, perform the following steps: 1. Make sure that you have prepared your system for the update, as described in Section 2.1. 2. Log in to the SYSTEM account on the boot server. 3. Shut down all other nodes in the cluster that boot from the first system disk. 4. Apply the update to the first system disk, according to the instructions in Section 2.4. 5. To update the second disk, perform the following steps: a. Log in to the SYSTEM account on a satellite node that boots from the second system disk. b. Shut down all other nodes in the cluster that boot from the second system disk. c. Apply the update to the second system disk, according to the instructions in Section 2.4. When the update is complete, perform the postinstallation tasks described in Section 2.5. 2-6 Updating to OpenVMS Alpha Version 7.1-1H1 2.4 Applying the OpenVMS Alpha Version 7.1-1H1 Update 2.4 Applying the OpenVMS Alpha Version 7.1-1H1 Update To update the OpenVMS Alpha Version 7.1 operating system to Version 7.1-1H1, complete the following steps: 1. If you are updating from a local CD-ROM drive, place the OpenVMS Alpha Version 7.1-1H1 distribution CD-ROM in the drive. If you are updating from an InfoServer system, the operating system CD-ROM is already in the drive (as described previously in Section 2.2). 2. If you are updating from a local CD-ROM drive, start the VMSINSTAL command procedure by entering a command in the following format: $ @SYS$UPDATE:VMSINSTAL AXPVMSU1H1071 DKA0: OPTIONS N Note that in this example, DKA0 is the device name of the source drive that holds the OpenVMS Alpha distribution CD-ROM. The OPTIONS N portion of the command indicates that you want to display the release notes option menu. If you are updating from an InfoServer system, start the VMSINSTAL command procedure by entering a command in the following format: $ @SYS$UPDATE:VMSINSTAL AXPVMSU1H1071 DAD1: OPTIONS N Note that DAD1 is the device name for the InfoServer drive that holds the OpenVMS Alpha distribution CD-ROM. The OPTIONS N portion of the command indicates that you want to display the release notes option menu. 3. As the update procedure begins, VMSINSTAL displays messages similar to the following: OpenVMS ALPHA Software Product Installation Procedure V7.1-1H1 It is 12-JUN-1997 at 11:26 Enter a question mark (?) at any time for help. * Are you satisfied with the backup of your system disk [YES]? If you backed up the system disk, press the Return key and go to step 4. 2-7 Updating to OpenVMS Alpha Version 7.1-1H1 2.4 Applying the OpenVMS Alpha Version 7.1-1H1 Update If you have not yet backed up the system disk, do the following: a. Enter No and press the Return key. VMSINSTAL returns to DCL level to permit you to perform the backup. b. Back up the system disk. c. When the backup is complete, restart the update procedure at step 1 in this section. 4. The procedure displays the following messages: The following products will be processed: AXPVMSU1H1 V7.1 Beginning installation of AXPVMSU1H1 V7.1 at 11:26 %VMSINSTAL-I-RESTORE, Restoring product save set A ... 5. With OPTIONS N selected, the procedure then displays the following message: 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 option 2 to print the release notes. The system displays the following message: * Do you want to continue the installation? [NO] If you want to continue with the update, enter Yes and press the Return key. If you want to abort the update procedure, enter No and press the Return key. In either case, if you select option 1, 2, or 3, the release notes will be displayed or printed according to your choice. 6. The procedure displays the following messages: 2-8 Updating to OpenVMS Alpha Version 7.1-1H1 2.4 Applying the OpenVMS Alpha Version 7.1-1H1 Update %VMSINSTAL-I-RELMOVED, Product's release notes have been moved to SYS$HELP. To complete the installation of this product, you should reboot the system. If it is not convenient to reboot at this time, then enter No to the following question. The installation of this kit will continue and the files moved to their appropriate locations without forcing the system to reboot upon completion of the installation. The system can then be rebooted at some more convenient time to actually have this update take effect. Entering YES will cause the system to automatically reboot upon the installation of this kit. * Will you allow a system shutdown after this product is installed [YES]? * How many minutes for system shutdown [7]: 7. After you respond to the questions, the procedure continues with a display similar to the following: No more questions will be asked ... Now applying AXPVMSU1H1071 ... 1) APB (new image) . . . %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories... 8. When VMSINSTAL completes the update, it displays messages similar to the following: Installation of AXPVMSU1H1 V7.1 completed at 11:30 Adding history entry in VMI$ROOT:[SYSUPD]VMSINSTAL.HISTORY Creating installation data file: VMI$ROOT:[SYSUPD]AXPVMSU1H171.VMI_DATA 9. If you specified automatic shutdown in your earlier response, the procedure then shuts down the system automatically. If you did not specify automatic shutdown, shut down the system manually. 10.Reboot the system with the updated system disk. If you have a cluster environment, reboot the nodes that use the newly updated system disk. 2-9 Updating to OpenVMS Alpha Version 7.1-1H1 2.5 Tasks to Perform After the Update 2.5 Tasks to Perform After the Update After you apply an update to your system, DIGITAL recommends that you perform the following tasks: o Set the correct date and time: - Use the following command to set the time in a nonclustered node: $ SET TIME = 12-JUN-1997:11:22:00 - Use the following commands to set the time in a cluster: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> SET PROFILE/PRIVILEGE=(LOG_IO,SYSLCK) SYSMAN> CONFIGURATION SET TIME 12-JUN-1997:11:22:00 SYSMAN> EXIT Refer to your System Management manuals for more information about how the operating system maintains the date and time and how to adjust those settings (for example, to allow for daylight saving time). o If you want a listing of the images replaced by this update, print the following file: $ PRINT SYS$UPDATE:VMS$SPECIAL_AXPVMSU1H1071.DAT o Display the free block count on the system disk by entering the following command: $ SHOW DEVICE SYS$SYSDEVICE: o The VMSINSTAL procedure copies the release notes to the file SYS$HELP:AXPVMSU1H1071.RELEASE_NOTES. You can print this file on a line printer or display it at a terminal. o DIGITAL recommends that you run AUTOGEN following the update. 2-10