Updated: 11 December 1998

OpenVMS Alpha Version 7.2 Upgrade and Installation Manual

This appendix contains information that supplements the license instructions in this manual and in the OpenVMS License Management Utility Manual.

After you install the OpenVMS Alpha operating system, you must register OpenVMS Alpha licenses, which let you use the OpenVMS Alpha operating system. You must also register the licenses for the OpenVMS Alpha layered products you have purchased, such as DECnet for OpenVMS. (Note that after an upgrade, however, you do not have to reregister licenses for the OpenVMS Alpha operating system or for the layered products.) To register a license, you need to obtain a Product Authorization Key (PAK). A PAK is a printed document provided by Compaq that contains the appropriate information to authorize access to software on an Alpha computer (or in an OpenVMS Cluster environment). You can obtain a PAK from a Compaq support representative in the same way as you obtain software.

C.1 Using the License Unit Requirement Table (LURT)

Many PAKs contain a table name in the availability or activity fields. This name refers to a column in the License Unit Requirement Table (LURT), which is shown in Table C-1. Column A in the LURT indicates the number of license units required for each processor listed in the System Marketing Model column. Column H refers to layered products you may choose to register as well. For example, if your PAK specifies availability = A, you would require 50 license units to load the license on a DEC 3000 Alpha Model 500 series computer, or 500 license units to load the license on a DEC 7000 Alpha Model 610 computer.

Note that some PAKs specify MOD_UNITS in the options field. The MOD_UNITS option allows the system manager to use the DCL command LICENSE MODIFY/UNITS to temporarily increase the size of the PAK. This permits a product to be used, in certain emergency situations, on a processor larger than the processor size specified in the license. Check your license terms and conditions before modifying license units. Reset the PAK size to its original size after the emergency situation is resolved.

Table C-1 License Unit Requirement Table (LURT)

System Marketing Model	A	H
ALPHAbook 1	12	1050
AlphaServer 400	12	1050
AlphaServer 800, 1000, 1000A	15	1050
AlphaServer 1200 (1 CPU)	25	1050
AlphaServer 1200 (2 CPU)	75	1050
AlphaServer 2000, 2000A (1 CPU)	400	1100
AlphaServer 2000, 2000A (2 CPU)	500	1100
AlphaServer 2100, 2100A (1 CPU)	400	1100
AlphaServer 2100, 2100A (2 CPU)	500	1100
AlphaServer 2100, 2100A (3 CPU)	600	1100
AlphaServer 2100, 2100A (4 CPU)	700	1100
AlphaServer 4100 (1 CPU)	400	1100
AlphaServer 4100 (2 CPU)	500	1100
AlphaServer 4100 (3 CPU)	600	1100
AlphaServer 4100 (4 CPU)	700	1100
AlphaServer 8200 (1 CPU)	2000	1150
AlphaServer 8200 (2 CPU)	2100	1150
AlphaServer 8200 (3 CPU)	2200	1150
AlphaServer 8200 (4 CPU)	2300	1150
AlphaServer 8200 (5 CPU)	2400	1150
AlphaServer 8200 (6 CPU)	2500	1150
AlphaServer 8400 (1 CPU)	2600	1150
AlphaServer 8400 (2 CPU)	2700	1150
AlphaServer 8400 (3 CPU)	2800	1150
AlphaServer 8400 (4 CPU)	2900	1150
AlphaServer 8400 (5 CPU)	3000	1150
AlphaServer 8400 (6 CPU)	3100	1150
AlphaServer 8400 (7 CPU)	3200	1150
AlphaServer 8400 (8 CPU)	3300	1150
AlphaServer 8400 (9 CPU)	3400	1150
AlphaServer 8400 (10 CPU)	3500	1150
AlphaServer 8400 (11 CPU)	2600	1150
AlphaServer 8400 (12 CPU)	2600	1150
AlphaStation 205, 250, 255, 500	12	1050
AlphaStation 400	12	1050
AlphaStation 600	12	1050
DEC 2000-300/300S	12	1050
DEC 2000-500/500S	12	1050
DEC 3000-300	15	1050
DEC 3000-300L	15	1050
DEC 3000-400/400S	20	1050
DEC 3000-600/600S	20	1050
DEC 3000-500/500S	50	1100
DEC 3000-500X	50	1100
DEC 3000-800/800S	50	1100
DEC 4000-610	300	1150
DEC 4000-620	400	1200
DEC 4000-710	300	1150
DEC 4000-720	400	1200
DEC 7000-610	500	1200
DEC 7000-620	600	1250
DEC 7000-630	700	1250
DEC 7000-640	800	1250
DEC 10000-610	800	1250
DEC 10000-620	900	1300
DEC 10000-630	1000	1300
DEC 10000-640	1100	1300

• A---The number of OpenVMS Alpha operating system license units (Unlimited or Base) required for the system.
• B through G---Omitted from table; reserved for future use.
• H--- The number of OpenVMS Alpha layered products license units required for the system.

C.2 License Management Facility (LMF) Notes

• If you do not have a valid OpenVMS Alpha license that is registered and activated, the system displays a warning message as part of system startup and restricts system use to the operator's console, OPA0.
• If a checksum error is displayed when you register a license, check all the fields of data that you entered, including the checksum itself.
• After your PAKs are registered, they are activated (loaded) automatically as part of each system startup.
• If an OpenVMS Alpha license is registered with insufficient license units, the system displays the following message when the user (process) attempts to log in:

  %LICENSE-F-EXCEEDED, licensed product has exceeded current license limits

  Users can always log in to the operator's console, OPA0, however.

• The default LICENSE database is located in the file SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB. You can move the database, although Compaq does not recommend doing so. If you move the database, you must either define the logical name LMF$LICENSE at the system level to point to the new database or use the /DATABASE=filespec qualifier with all LICENSE commands. To redirect LMF to another database location on a more permanent basis, add the following line to the command procedure SYS$MANAGER:SYLOGICALS.COM:

  $ DEFINE/SYSTEM LMF$LICENSE device:[directory]LMF$LICENSE.LDB

  
  If you specify a device other than SYS$SYSDEVICE, you must also mount the specified disk from the SYLOGICALS.COM command procedure.

• Each OpenVMS Alpha find license is restricted to a single node for permanent PAKs. You must assign a System Communications Services (SCS) name to the license when you register with the VMSLICENSE.COM command procedure, or you must enter a LICENSE MODIFY/INCLUDE=node-name command after you register the license.

  Note The SCS node name is not necessarily the DECnet node name. SCSNODE is a system parameter; it can be a maximum of six alphabetic characters.

Availability Product Authorization Keys (PAKs) are available for the OpenVMS Alpha operating system. An OpenVMS Alpha PAK is identified by the keyword ALPHA in the PAK's option field. Note the following restrictions:

• PAKs having the ALPHA option can be loaded and used only on Alpha computers. However, they can safely reside in a license database (LDB) shared by both VAX and Alpha systems.
• Because the LMF for Alpha systems is capable of handling all types of PAKs, including those for VAX systems, Compaq recommends that you perform your LDB tasks using the Alpha LMF.
• Availability PAKs for VAX systems (availability PAKs without the ALPHA option) will not load on Alpha systems. Only those availability PAKs containing the ALPHA option will load on Alpha systems.
• Other PAK types such as activity (also known as concurrent or n-user) and personal use (identified by the RESERVE_UNITS option) work on both VAX and Alpha systems.
• Avoid using the following LICENSE commands from a VAX system on a PAK containing the ALPHA option:
  • REGISTER
  • DELETE/STATUS
  • DISABLE
  • ENABLE
  • ISSUE
  • MOVE
  • COPY
  • LIST
• Caution: By default, all Alpha availability PAKs look disabled to a VAX system. Never use the DELETE/STATUS=DISABLED command from a VAX system on an LDB that contains Alpha PAKs. If you do, all Alpha PAKs will be deleted.
• With the exception of the DELETE/STATUS=DISABLED command, if you inadvertently use one of the previously listed LICENSE commands on an Alpha PAK while using a VAX system, the PAK and the database will not be adversely affected. Repeat the command using LMF running on an Alpha system, and the PAK should return to a valid state.
• If you do not repeat the command using LMF on an Alpha system, the system that you intended to disable will remain enabled (the system is not otherwise affected). Only the Alpha LMF can disable an Alpha PAK.
  However, if you attempt to use any of the previously listed commands on a PAK located in an LDB that is shared with a VAX system, the following serious problems may result:
  • Because Alpha PAKs look disabled to a VAX system, they are normally ignored at load time by VAX systems. However, if one of the previously listed commands is entered from a VAX system and the PAK information is not set to a valid state by an Alpha system, there is a chance the VAX system will attempt to load the Alpha PAK. Because the VAX system will be unable to load the PAK, the VAX LMF will report an error.
  • Even if a valid VAX PAK for the affected product is in the LDB, it too may not load. In this case, system users might be denied access to the product.
  
  If the PAK cannot be restored to a valid state because all Alpha systems are inaccessible for any reason, use your VAX system to disable the Alpha PAK. This prevents your VAX system from attempting to load the Alpha PAK.

During the OpenVMS installation or upgrade procedure, the OpenVMS Management Station software is automatically installed on your OpenVMS system disk when you accept all the default values.

If you did not accept the default values and did not manually select the OpenVMS Management Station component, you must add those files to your OpenVMS system disk before you follow the instructions in this appendix.

Use the OpenVMS operating system CD-ROM and the DCL command PRODUCT INSTALL TNT to add the OpenVMS Management Station files to your system. (See the OpenVMS System Management Utilities Reference Manual: M--Z for complete information about using the PRODUCT command.)

After you have ensured that OpenVMS Management Station software is installed on your system, follow the procedures described in this appendix.

D.1 Preparing Your OpenVMS System

You must prepare your OpenVMS system to run the server software so that your system can properly interact with the PC running the client software. The procedures include the following:

• Set up within a mixed-architecture cluster environment (if applicable).
• Start the server on other nodes.
• Update the printer and storage database.
• Edit the system files.
• Allow OpenVMS Management Station to control the printer and storage environment.
• Keep your printer environment up to date.
• Check if running third-party TCP/IP stacks.
• Recover from a failure.
• Determine and report problems.

The OpenVMS Management Station server creates several configuration files:

• TNT$UADB.DAT
• TNT$ACS.DAT
• TNT$JOURNAL.TNT$TRANSACTION_JOURNAL
• TNT$MONITOR.DAT
• TNT$MONITOR.TNT$MONITOR_JOURNAL
• TNT$EMERGENCY_MOUNT.COM

In a common-environment cluster with one common system disk, you use a common copy of each of these files located in the SYS$COMMON:[SYSEXE] directory on the common system disk, or on a disk that is mounted by all cluster nodes. No further action is required.

However, to prepare a common user environment for an OpenVMS Cluster system that includes more than one common VAX system disk or more than one common Alpha system disk, you must coordinate the files on those disks.

The following rules apply:

• Disks holding common resources must be mounted early in the system startup procedure, such as in the SYLOGICALS.COM procedure.
• You must ensure that the disks are mounted with each cluster reboot.

Follow these steps to coordinate files:

1. Decide where to locate the files. In a cluster with multiple system disks, system management is much easier if the common system files are located on a single disk that is not a system disk.
2. Copy TNT$UADB.DAT, TNT$ACS.DAT, TNT$MONITOR.DAT, TNT$MONITOR.TNT$MONITOR_JOURNAL, TNT$EMERGENCY_MOUNT.COM, and TNT$JOURNAL.TNT$TRANSACTION_JOURNAL to a location other than the system disk.
3. Edit the file SYS$COMMON:[SYSMGR]SYLOGICALS.COM on each system disk and define logical names that specify the location of the cluster common files.

   Example
   
   If the files will be located on $1$DJA16, define logical names as follows:

   $ DEFINE/SYSTEM/EXEC TNT$ACS - _$ $1$DJA16:[VMS$COMMON.SYSEXE]TNT$ACS.DAT

   
   TNT$EMERGENCY_MOUNT.COM will be created in SYS$SYSTEM or in the directory pointed to by the TNT$ACS logical, if the logical exists.

   $ DEFINE/SYSTEM/EXEC TNT$UADB - _$ $1$DJA16:[VMS$COMMON.SYSEXE]TNT$UADB.DAT $ DEFINE/SYSTEM/EXEC TNT$JOURNAL - _$ $1$DJA16:[VMS$COMMON.SYSEXE]TNT$JOURNAL.TNT$TRANSACTION_JOURNAL $ DEFINE/SYSTEM/EXEC TNT$MONITOR - _$ $1$DJA16:[VMS$COMMON.SYSEXE]TNT$MONITOR.DAT $ DEFINE/SYSTEM/EXEC TNT$MONITORJOURNAL - _$ $1$DJA16:[VMS$COMMON.SYSEXE]TNT$MONITOR.TNT$MONITOR_JOURNAL

4. To ensure that the system disks are mounted correctly with each reboot, follow these steps:
   1. Copy the SYS$EXAMPLES:CLU_MOUNT_DISK.COM file to the [VMS$COMMON.SYSMGR] directory, and edit it for your configuration.
   2. Edit SYLOGICALS.COM and include commands to mount, with the appropriate volume label, the system disk containing the shared files.

      Example
      
      If the system disk is $1$DJA16, include the following command:

   $ @SYS$SYSDEVICE:[VMS$COMMON.SYSMGR]CLU_MOUNT_DISK.COM - _$ $1$DJA16: volume-label

If you plan to run OpenVMS Management Station on more than one node in an OpenVMS Cluster without a reboot, you need to start the software on those nodes.

Use SYSMAN to start the server as follows:

$ @SYS$STARTUP:TNT$STARTUP.COM

or, you can log into each node that shares the SYS$COMMON: directory and enter the following command:

$ @SYS$STARTUP:TNT$STARTUP.COM

If you are performing an upgrade or a reinstallation and OpenVMS Management Station is already running on the node, add the RESTART parameter to the startup command, as follows:

$ @SYS$STARTUP:TNT$STARTUP.COM RESTART

D.1.3 Error Log Information

OpenVMS Management Station writes error log information to the file TNT$SERVER_ERROR.LOG. This error log is created in the SYS$SPECIFIC:[SYSEXE] directory. If you start the OpenVMS Management Station server on multiple nodes in a cluster, which is recommended, there will be multiple server error logs.

D.1.4 Update the Printer and Storage Database

When you installed OpenVMS Management Station, the installation started the OpenVMS Management Station server on the installation node. If this installation was an upgrade, the server converts the existing OpenVMS Management Station database to the V3.0 format. If this was a new installation, the server creates an initial version of the database file TNT$ACS.DAT and invokes the update functions automatically.

To complete the database, start the OpenVMS Management Station server on each node in your cluster. The instances of the server communicate with each other to determine device, queue, and volume information, and the server must be running on each node for this communication to take place.

D.1.5 Edit the System Files

To start the OpenVMS Management Station server from your system startup files, insert one of the following commands into your system startup procedures (probably SYS$MANAGER:SYSTARTUP_VMS.COM) after both the Queue Manager and network are started, but immediately prior to the ENABLE AUTOSTART/QUEUES.

Note that the effect of TNT$STARTUP BOOT, with no second parameter, has not changed from earlier releases. This command starts any printer queues that are not yet started and are managed by OpenVMS Management Station, but does not mount any volumes.

Add the following command line to the system shutdown file,
SYS$MANAGER:SYSHUTDWN.COM:

$ @SYS$STARTUP:TNT$SHUTDOWN.COM

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6522PRO_014.HTML