Document revision date: 30 March 2001
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

Compaq Advanced Server for OpenVMS
Guide to Managing Advanced Server Licenses


Previous Contents Index


Chapter 3
Configuring License Servers

This chapter explains some License Server configuration changes you may need to make and the impact of those changes on the client(s). The License Server configuration information is explained in the following sections:

3.1 License Server State Files

The License Server stores information in a database called the License Server state file, which exists on the system as:


PWRK$LICENSE:PWRK$LICENSE_SERVER_STATE.DAT 

The information that is stored in the License Server state file includes the following:

The following sections provide information about the License Server state file and describe the procedure for recreating it.

3.1.1 License Server Name

The License Server state file stores the name of the License Server. This name is used to facilitate communication between the License Server and clients. When a client is assigned a license, part of the license information saved by the client is the name of the License Server that issued the license. This name is used to contact the License Server when the client attempts to verify its licenses. The name is defined in the following format:


PWRK$Lname

When the License Server is started for the first time, the template License Server state file provided during installation does not contain the License Server name. The License Server determines its name as follows:

In either case, the value chosen as the name portion of the License Server name is used to form the License Server name, which is then stored in the License Server state file. Once established, the License Server uses the name stored in the state file, even if the SYS$CLUSTER_NODE or SCSNODE values should change.

3.1.2 Creating a New License Server State File

If the License Server state file is rendered unusable, the License Server will not run. You must create a new License Server state file if this happens. Follow these steps to create a new License Server state file:

  1. Shut down the License Server.
    In a cluster, shut down the License Server on all nodes.
  2. If the License Server state file exists, delete the current License Server state file, or rename it to another filename.
    In a cluster, do this on only one node because the state file is common to all nodes.
  3. Restart the License Server.
    When the License Server starts and does not find a License Server state file, it creates a new state file and logs a message to the License Server log file stating that a new state file has been created and that the License Server has disabled itself.
  4. To enable the License Server:
    1. Invoke the License Manager.
    2. From the Main menu, choose Options.
    3. From the Options menu, choose Server Enable/Disable.
    4. Choose Enable Server.
    5. Choose OK.

Once enabled, the License Server determines its name and initializes the License Server state file before it responds to any client requests. See Chapter 4, Managing Licenses on the OpenVMS Platform, for information about using the License Manager.

Because the License Server begins running with a new License Server state file, all information from any previous License Server state file is lost, including the License Server name, any group information, and all records of client licenses that were previously assigned. If license groups were being used, you must recreate the groups and allocate licenses to them.

When the License Server starts with the new state file and determines its name, two possible problems can occur:

3.2 Moving a License Server to a Different System

There are two recommended methods for changing the system on which the License Server is run. You can move the License Server and retain the same server name or you can move the License Server and change the server name.

When you move the License Server and retain the server name, it is transparent to users. Clients will not notice that the License Server has moved.

When you move the License Server and change the server name, there is an impact on both server administration and clients:

Use the following procedures for moving the License Server and retaining the server name or moving the License Server and changing the server name.

3.2.1 Moving the License Server and Retaining the License Server Name

For the purposes of this example, the License Server is currently running on a system called SYS1, and the License Server is to be moved to a system called SYS2, which is not currently running a License Server.

  1. Shut down the License Server on SYS1.
  2. Reconfigure the file server on SYS1 so that the License Server is not started when the file server is started.
  3. Unload and delete all the client-based license PAKs from LMF on SYS1.
  4. Register and load all the client-based license PAKs that were deleted from LMF on SYS1 into LMF on SYS2.
  5. Install the file server software on SYS2, if not already done.
  6. Configure the file server on SYS2 to run the License Server, but do not start the License Server.
  7. Delete any template License Server state files on SYS2. For more information, see Section 3.1, License Server State Files.
  8. Copy the License Server state file from the PWRK$LICENSE directory on SYS1 to the PWRK$LICENSE directory on SYS2.
  9. Start the License Server on SYS2. The License Server finds and reads the License Server name it was previously using on SYS1 in the state file and continues to use them while running on system SYS2.
    Clients that were assigned licenses by the License Server running on SYS1 continue to verify their licenses (or get new licenses) from the License Server named "SYS1" running on system SYS2.

3.2.2 Moving the License Server and Changing the License Server Name

For the purposes of this example, the License Server is currently running on a system called SYS1, and the License Server is to be moved to a system called SYS2, which is not currently running a License Server.

  1. Install the file server on SYS2, if not already done.
  2. Configure the file server on SYS2 to run the License Server, but do not start the License Server.
  3. Shut down the License Server on SYS1.
  4. Unload and delete all the client-based license PAKs from LMF on SYS1.
  5. Register and load all the client-based license PAKs that were deleted from LMF on SYS1 into LMF on SYS2.
  6. Start the License Server on SYS2, causing the License Server on SYS2 to form the License Server name using "SYS2" as the node portion of the License Server name. The new name is stored in the License Server state file on SYS2.
  7. Using the License Manager, load the licenses into the License Server and define any groups that were defined for the License Server on SYS1. This recreates a similar License Server state file on SYS2 as was on SYS1, with the exception of the client licenses assigned on SYS1. See Chapter 4, Managing Licenses on the OpenVMS Platform, for information about how to use the License Manager.
  8. Start the License Server on SYS1, causing the License Server on SYS1 to synchronize the count of assignable licenses with LMF. Because all the client-based licenses have been removed from LMF, all licenses previously assigned by the License Server on SYS1 are automatically revoked.
  9. Leave the License Server on SYS1 running until all clients who were issued licenses by the License Server on SYS1 discover their licenses have been revoked. Notification that the license has been revoked and is invalid occurs when clients boot and attempt to verify their license. After a client's license is revoked, the SYS2 License Server can assign a new license.
    It may be necessary to modify the client configuration if the License Server name SYS1 was specified.

3.3 Controlling License Version Lookup

If there are no available licenses for the version of the server that the client requests, the licensing software looks for a license for a higher version.

By default, the software looks for licenses for subsequent major and minor releases up to 4.3 versions beyond the requested version.

For example, if the request is for Version 5.1, and no licenses are available, the License Server looks for the following license versions in the LMF database:

5.2, 5.3, 5.4
6.0, 6.1, ..., 6.4
7.0, 7.1, ..., 7.4
8.0, 8.1, ..., 8.4
9.0, 9.1, ..., 9.4

You control the version limits by defining the following logical name in the systemwide logical name table before starting the licensing software:


PWRK$LICENSE_VERSION_LIMIT 

You can define the logical name in two different formats:

"+MM.mm"
"MM.mm"

For MM substitute the major release number; for mm substitute the minor release number. The + means that the version is incremental. For example, the highest version searched is the current version plus the incremental version. Without the +, the release number is the absolute value and the search ends at the specified version.

Example 1:


$ DEFINE/SYSTEM PWRK$LICENSE_VERSION_LIMIT "+1.3" 

In this example, the license software looks for licenses for one major release beyond the requested version, and for licenses for three point releases beyond the requested minor release version. If the request is for Version 5.1, and no licenses are available, the License Server or License Registrar looks for licenses in the LMF for the following versions:

5.2, 5.3, 5.4
6.0, 6.1, 6.2, 6.3, 6.4

Example 2:


$ DEFINE/SYSTEM PWRK$LICENSE_VERSION_LIMIT "6.2" 

In this example, the license software looks for licenses for major software versions up to and including Version 6, and for licenses for point releases up to and including .2. If the request is for Version 5.1, and no licenses are available, the License Server or License Registrar looks for licenses in the LMF for the following versions:

5.2
6.0, 6.1, 6.2

3.3.1 Acquiring a Different Client-Based License than Requested

In the case where a client is attempting to acquire a client-based PATHWORKS for OpenVMS (Advanced Server) license and no PATHWORKS for OpenVMS (Advanced Server) licenses are available on the local system, the license lookup function may find an Advanced Server for OpenVMS license for the client if one is available. (Advanced Server for OpenVMS licenses are valid for accessing both PATHWORKS for OpenVMS (Advanced Server) servers and Advanced Server for OpenVMS servers.)

3.4 Controlling Where the License Server Runs in an OpenVMS Cluster

Installing the License Server in an OpenVMS Cluster environment provides license service failover in the event that license services terminate on the node running the active License Server.

Normally, the License Server process (PWRK$LICENSE_S) is started on every node of the OpenVMS Cluster that starts the file server, but only one License Server process is active at any one time. The other License Server processes remain dormant until an event, such as system shutdown or a system failure, causes the active License Server process to stop. When the active License Server stops, one of the dormant License Servers becomes active and continues to provide license services to clients.

In most cases, Compaq recommends that you run the License Server on all nodes of the cluster that run the file server, for maximum availability. The exception is the case where the License Server will serve licenses to WAN clients. Then you will want to limit the License Server to running on one node of the cluster.

In an OpenVMS Cluster environment, the License Server state file is maintained cluster-wide. The file server directory tree starting at PWRK$ROOT must be on a disk that is common to all nodes on the OpenVMS Cluster.

There are a number of ways to determine which node is running the active License Server:

3.4.1 How to Specify Where License Servers Run in a Cluster

To prevent the License Server from running on a particular node, you can add the following logical name definition to that node's startup command procedure:


$ DEFINE/SYSTEM PWRK$LICENSE_SERVER_INHIBIT 1 

Note

In a cluster environment where all nodes use the same startup procedure, check the node name before executing the DEFINE command.

The SYS$STARTUP:PWRK$LICENSE_S_START.COM file has information about this logical. The initial value of this logical (and its only value, as it does not define a dynamic parameter) is logged in the License Server log file
PWRK$LOGS:PWRK$LICENSE_SERVER_servername.LOG.

Note

The Advanced Server for OpenVMS License Server interprets the value associated with the PWRK$LICENSE_SERVER_INHIBIT configuration parameter in the same manner as does the PATHWORKS V6 for OpenVMS server.

This is different from the way a PATHWORKS V5 for OpenVMS server interprets it. Under PATHWORKS V5 for OpenVMS, a value of zero for this parameter indicates that the License Server will be prevented from running on the local node. With Advanced Server for OpenVMS, the configuration parameter value is interpreted as follows:

  • A value of one means TRUE, which prevents the License Server from running.
  • A value of zero means FALSE, which allows the License Server to run.

The following example shows how to prevent the License Server from running on node SPOT:


$ IF F$TRNLNM("SYS$NODE") .EQS. "SPOT::" THEN - 
DEFINE/SYSTEM PWRK$LICENSE_SERVER_INHIBIT 1 

The next example shows how to allow the License Server to run only on node ROVER:


$ IF F$TRNLNM("SYS$NODE") .NES. "ROVER::" THEN - 
DEFINE/SYSTEM PWRK$LICENSE_SERVER_INHIBIT 1 

You can specify the following logical name definition to define which nodes you want the License Server to run on. By default, if this logical is not defined, the License Server will run on all nodes.


$ DEFINE/SYSTEM PWRK$LS_LICENSE_NODES "node1, node2, node3" 

Each node name that you add to this comma-separated list is a node that is allowed to run the License Server. Any node in your OpenVMS Cluster that is not specified in the list when the logical is defined, will not run the License Server.

Note

If you define PWRK$LS_LICENSE_NODES, and define
PWRK$LICENSE_SERVER_INHIBIT (described above), the settings you define with PWRK$LS_LICENSE_NODES supersede any settings defined with PWRK$LICENSE_SERVER_INHIBIT.

3.5 Synchronizing the License Server Database with the LMF Database

The number of client-based licenses available for a product may change because additional product licenses are added to the LMF database, or existing licenses are unloaded, disabled, deleted, or expired from the LMF database.

The License Server must check the LMF database to verify license counts for products currently in the License Server database. The License Server database is updated to reflect LMF database changes at the following times:

You can change the time at which the synchronization occurs by defining the logical PWRK$LSLMFSYNCHMINUTES, as described in Section 3.5.2, Scheduling the LMF Synchronization.


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6554PRO_003.HTML