You must register and load your ACMS license before you can install or use ACMS. This appendix explains how to register and load your license.

Section B.1 describes an ACMS License Product Authorization Key (PAK).

Section B.2 describes how to load and register your ACMS license using the command procedure VMSLICENSE.COM.

Section B.3 describes how to load and register your ACMS license using the LICENSE DCL commands.

For more information on OpenVMS licensing, see OpenVMS License Management Utility Manual, and the DCL command HELP LICENSE.

B.1 Sample ACMS License PAK

The ACMS License PAK is a paper document that contains information about your ACMS license. When you register your ACMS license on your system, information from this document is loaded into the license database.

Each PAK has fourteen fields of information. Depending on your license agreement, some fields might contain data, while others might be blank.

Table B-1 lists all the fields on a PAK, along with typical data for an ACMS PAK.

Table B-1 Product Authorization Key Fields

Field Name	Typical ACMS Information
ISSUER:	DEC
AUTHORIZATION NUMBER:	US-10-THM-0
PRODUCT NAME:	ACMS 1
PRODUCER:	DEC
NUMBER OF UNITS:	1200
VERSION:	4.3
PRODUCT RELEASE DATE:	(none)
KEY TERMINATION DATE:	(none)
AVAILABILITY CODE:	F
ACTIVITY TABLE CODE:	(none)
KEY OPTIONS:	MOD_UNITS
PRODUCT TOKEN:	(none)
HARDWARE I.D.:	(none)
CHECKSUM:	1-NTIN-DCIN-TCTA-NYMR

You can register and load your ACMS license using the OpenVMS command procedure VMSLICENSE.COM. To invoke this procedure, first log in to the system manager's account, SYSTEM, and then execute the following command:

$ @SYS$UPDATE:VMSLICENSE

The procedure displays a menu; press [Return] to choose the default menu item, registering a PAK. The procedure then asks if you have your PAK; press [Return] to choose the default answer, YES.

The procedure now asks you to supply the data for each field on your PAK. For each field, type in the data exactly as it appears on the PAK.

When you have supplied all the PAK information, the procedure displays the information you provided, in the same form as it appears on the PAK, and asks if it is correct. If all the information is correct, press [Return] to choose the default answer, YES.

The procedure then registers the PAK in the license database, and asks if you want to load the license. Press [Return] to choose the default answer, YES.

When you are finished, select menu item 99 to exit from the procedure.

B.3 Using LICENSE DCL Commands

You can register and load your ACMS license using the DCL commands LICENSE REGISTER and LICENSE LOAD. Log in to the system manager's account, SYSTEM, before executing these commands.

The LICENSE REGISTER command accepts parameters and qualifiers that correspond to the fields on your PAK. The general syntax for this command is:

LICENSE REGISTER product-name [/qualifiers]

Table B-2 lists all the fields on a PAK, along with their LICENSE LOAD parameters and qualifiers.

Table B-2 LICENSE LOAD Parameters and Qualifiers

Field Name	LICENSE REGISTER Qualifier
ISSUER:	/ISSUER="string"
AUTHORIZATION NUMBER:	/AUTHORIZATION=string
PRODUCT NAME:	(product-name parameter)
PRODUCER:	/PRODUCER="string"
NUMBER OF UNITS:	/UNITS=number
VERSION:	/VERSION=nn.m
PRODUCT RELEASE DATE:	/RELEASE_DATE=date
KEY TERMINATION DATE:	/TERMINATION_DATE=date
AVAILABILITY CODE:	/AVAILABILITY=code or /AVAILABILITY=CONSTANT=number
ACTIVITY TABLE CODE:	/ACTIVITY=code or /ACTIVITY=CONSTANT=number
KEY OPTIONS:	/OPTION=keyword
PRODUCT TOKEN:	/TOKEN=string
HARDWARE I.D.:	/HARDWARE_ID=string
CHECKSUM:	/CHECKSUM=string

For example, the following DCL commands register and load the PAK information supplied in Table B-1:

$ LICENSE REGISTER ACMS - _$ /ISSUER="DEC" - _$ /AUTHORIZATION=US-10-THM-0 - _$ /PRODUCER="DEC" - _$ /UNITS=1200 - _$ /VERSION=4.3 - _$ /AVAILABILITY=F - _$ /OPTION=MOD_UNITS - _$ /CHECKSUM=1-NTIN-DCIN-TCTA-NYMR $ LICENSE LOAD ACMS

This appendix describes how to modify ACMS help and message text, for example, to translate them to languages other than English.

The ACMS kit includes a save set that contains the files you can use to translate the contents of ACMS message files and help text to languages other than English. This section provides information on how to restore the save set from the kit.

All source files for the messages and help text are stored in a BACKUP save set in the kit. Restore this save set to a directory and modify it there. Follow these instructions to restore the save set:

1. Mount the kit.
   If the kit is on magtape, mount it using the /FOREIGN qualifier. For example, to mount a kit on tape drive MTA0:, enter:

   $ MOUNT/FOREIGN MTA0:

   
   If the kit is on disk, mount it using the /OVERRIDE=ID qualifier. For example, to mount a kit on RA90 drive $100$DUA31:, use the following command:

   $ MOUNT/OVERRIDE=ID $100$DUA31:

2. Restore the save set.
   To restore the save set, use the DCL command BACKUP and the save set name in the following format:

   BACKUP/LOG kit-device:<kit-name>.I /SAVE disk:[directory]

   
   The <kit-name> parameter denotes the software kit you are installing:

   • ACMSDEVA_043 --- if you are installing the Alpha development kit.
   • ACMSRTOA_043 --- if you are installing the Alpha run-time kit.
   • ACMSREMA_043 --- if you are installing the Alpha remote-access kit.
   • ACMSDEVV_043 --- if you are installing the VAX development kit.
   • ACMSRTOV_043 --- if you are installing the VAX run-time kit.
   • ACMSREMV_043 --- if you are installing the VAX remote-access kit.
   
   Restore the save set to an empty directory. For example, if you have an ACMS Alpha development kit that is mounted on MTA0: and you have created the directory DISK1:[MESSAGES] to hold the files, use the following DCL command BACKUP to restore the save set:

   $ BACKUP/LOG MTA0:ACMSDEVA_043.I/SAVESET DISK1:[MESSAGES]

   
   The ACMS save sets are stored in the [0,0] directory on disk kits. If, for example, you have an ACMS Alpha run-time kit that is mounted on $100$DUA31:, and you have created the directory DISK1:[MESSAGES] to hold the files, use the following DCL BACKUP command to restore the save set:

   $ BACKUP/LOG $100$DUA31:[0,0]ACMSRTOA_043.I/SAVESET - _$ DISK1:[MESSAGES]*

3. Make changes to the files.
   After restoring the kit, you can print the file CHANGING_MESSAGES.MEM, which contains instructions on how to change the help text files, change the message files, and install the modified files on the target system. This file also includes instructions to change the character ordering sequence used by the CONTROL FIELD and SELECT FIRST statements.

If you want to use DECdtm services on a node, you must create a transaction log for that node. In an OpenVMS Cluster system, you must create a transaction log for each node in the cluster. This appendix describes the following:

• Prerequisites for creating a transaction log
• Planning the size and location of transaction logs
• Setting up and creating transaction logs
• Example of creating transaction logs for a cluster

For more information about DECdtm services and the commands described in this appendix, see the OpenVMS documentation set.

D.1 Prerequisites for Creating a Transaction Log

Before you create a transaction log for a node, the following prerequisites must be met:

• You must have the SYSPRV privilege.
• The node must be running OpenVMS Alpha Version 6.2 or higher, excluding Version 7.0.
• The node must be running OpenVMS VAX Version 6.2 or higher, excluding Version 7.0.

The size and location of transaction logs can affect the performance of your system. Before you create transaction logs, plan how big to make the logs, and where you are going to put them. Although you can later move a transaction log and change the size to improve performance, careful planning reduces the need for changes.

If the performance of your system is adversely affected by either the location or size of the logs, refer to the OpenVMS documentation for the following information:

• Checking whether or not the transaction logs are the correct size
• Changing the size of transaction logs
• Moving transaction logs

When you create transaction logs, you specify the size of the log in blocks. By default, the size of each transaction log is 4000 blocks. This default size gives acceptable performance on most systems.

If you know the rate of transactions and their duration, use the following algorithm to calculate the transaction log size:

size = 40 * rate * duration

In this algorithm:

• size is the size (in blocks) of the transaction log.
• rate is the average number of transactions executed per second.
• duration is the average duration (in seconds) of each transaction.

For example, if the rate is 10 transactions per second and the duration is 12 seconds, the calculation is as follows:

size = 40 * 10 * 12 = 4800 blocks

In this example, the recommended size for the transaction log is 4800 blocks.

If you do not know the rate and duration of transactions, accept the default value of 4000 blocks.

D.2.2 Determining the Location for Transaction Logs

When deciding where to put the transaction log for a node, consider the following factors:

• Speed
  Select a high performance disk, such as a solid state disk, that is not heavily used.
• Availability
  High availability is achieved when you have multiple access paths to the data. Use a disk that can be accessed by the other nodes in the cluster when the node is down. This reduces the time that other transactions in the cluster are blocked while waiting for recovery from the node failure.
• Reliability
  Reliability is achieved when you have multiple copies of the data. A shadowed disk is more reliable than a nonshadowed disk, but may be slower than a nonshadowed disk because transaction logs are almost exclusively write-only.

You may have to choose which of these factors are most important. For example, if the node is a workstation, you may choose to give up speed for availability and reliability, by putting the transaction log on a shadowed HSC-based disk, instead of on a faster disk attached to the workstation.

If you have an OpenVMS Cluster, each node must have its own transaction log. To improve the performance of the transactions, distribute the logs among different disks on the system.

This section describes how to set up and create transaction logs. Before creating a transaction log, consider the recommendations for sizing and locating the log, as described in Section D.2. For an example of how to set up and create transaction logs for a three-node OpenVMS Cluster, refer to Section D.4.

To set up and create a transaction log:

1. Identify the directories where you want to put the transaction logs.
2. Create the log file in the directories.

DECdtm services uses the logical SYS$JOURNAL to locate transaction logs. For a single node, you must define SYS$JOURNAL to point to the directory that will contain the transaction log. In an OpenVMS Cluster, you define SYS$JOURNAL on each node as a search list that points to all the directories that will contain the transaction logs for the cluster. If you put transaction logs for all nodes in one directory, SYS$JOURNAL on each node points to that directory.

You must define SYS$JOURNAL in the system logical name table, in executive mode.

To create a transaction log file, use the CREATE LOGFILE command of the Log Manager Control Program (LMCP) Utility:

$ RUN SYS$SYSTEM:LMCP LMCP> CREATE LOGFILE file-spec /SIZE=size LMCP> EXIT

In this example:

• file-spec is the full file specification of the transaction log. The name of the file must be SYSTEM$node-name, where node-name is the name of the node. The file extension must be .LM$JOURNAL. If you omit the file extension in the command line, the file specification has the extension .LM$JOURNAL by default.
• size is the size of the transaction log in blocks. If you omit the /SIZE qualifier, the transaction log is created with the default size of 4000 blocks.

This section shows you how to set up and create transaction logs for a three-node OpenVMS Cluster system. In this example, cluster members and transaction log details are listed in Table D-1.

Table D-1 Transaction Log Requirements

	Transaction Log
Node Name	Location	Size (In Blocks)
ORANGE	DISK$USER1:[LOGFILES]	5000
RED	DISK$USER3:[LOGFILES]	4000
GREEN	DISK$LOG:[LOGFILES]	6000

To set up and create the transaction logs for the three-node OpenVMS Cluster, follow these steps. Before starting, ensure that all three disks are mounted on all three nodes.

1. For each node, define the logical SYS$JOURNAL to be a search list of all the directories in Table D-1, with the following command:

   $ DEFINE /SYSTEM /EXECUTIVE SYS$JOURNAL - _$ DISK$USER1:[LOGFILES], - _$ DISK$USER3:[LOGFILES], - _$ DISK$LOG:[LOGFILES]

   Note You can enter all of the commands to set up the cluster from one node, using the SYSMAN Utility.

2. Edit the common and node-specific versions of SYS$STARTUP:SYLOGICALS.COM files to include the definition of SYS$JOURNAL.
3. Enter the following commands to create the transaction log files:

   $ RUN SYS$SYSTEM:LMCP LMCP> CREATE LOGFILE DISK$USER1:[LOGFILES]SYSTEM$ORANGE/SIZE=5000 LMCP> CREATE LOGFILE DISK$USER3:[LOGFILES]SYSTEM$RED LMCP> CREATE LOGFILE DISK$LOG:[LOGFILES]SYSTEM$GREEN/SIZE=6000 LMCP> EXIT

   
   If you omit the /SIZE qualifier (for example, when creating the log for node RED), the transaction log is created with the default size of 4000 blocks.