HP OpenVMS Systems

Content starts here

HP 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 name used by the License Server that enable clients to access it
  • Information about the types and quantities of client-based licenses that are available to assign to clients
  • License group information
  • A record of the licenses the License Server has assigned to clients

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:

  • On a node in an OpenVMS Cluster, where an equivalence-name is defined for the logical SYS$CLUSTER_NODE, the node name portion of the value of the equivalence-name is used as the name portion of the License Server name.
  • On a standalone node, where the logical SYS$CLUSTER_NODE is not defined, the License Server uses the value of the SYSGEN SCSNODE parameter as the name portion of the License Server name.

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:

  • The License Server name is the same name as was previously used, but license groups are not defined.
    In this case, any client that was previously assigned a license by the License Server fails on its next attempt to verify the license, because the assignment information stored in the previous state file was lost and the client's license is marked as invalid. In this case, the client should attempt to acquire a new license after you recreate the licensing groups.
  • The License Server name is different than the name previously used, but the client license data file is not updated.
    In this case, clients cannot locate the License Server to verify their license because they are attempting to contact the License Server using the License Server's old name. You should delete the license data file on the client and reboot it so that it attempts to acquire a new license. If the licensing configuration template file specifies a License Server name, the configuration file must be changed. Then, when the client looks for a new license, it finds its new name, and it can acquire a new license.

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:

  • You must reenter all license group information on the new system using the License Manager and you must allocate licenses to each of the groups.
  • You must keep the original License Server running (even though it does not have any licenses it can assign) until all the clients find the new License Server.
  • The original License Server revokes client licenses so clients can request assigned licenses from the new server.

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.)

  • If the License Server determines that no PATHWORKS for OpenVMS (Advanced Server) licenses are available, the License Server will begin the lookup process again, looking for Advanced Server licenses (PWLMXXXCAnn.mm).
  • If the License Server finds an available Advanced Server license, it is assigned to the client and a virtual license is returned to the client.

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, HP 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:

  • Use the SHOW SYSTEM command.
    This command displays status information about current processes running on your system. The active License Server process is listed as PWRK$LICENSE_S with the state listed as HIB as shown in the following example:


    $ SHOW SYSTEM
    Pid      Process Name   State    Pri     I/O       CPU        Page
       .
       .
       .
    00000230 PWRK$LICENSE_S  HIB      6      191   0 00:00:01.67   777
       .
       .
       .
    

    This example shows only the License Server process. A dormant License Server is shown with its state indicated as LEF. When you enter the SHOW SYSTEM command, all of the currently running processes on the system are displayed.
  • Use the PWSHOW command.
    This is one of many commands that provide shortcuts for invoking certain server management commands and procedures. You can see a list of these commands by examining the contents of the file SYS$STARTUP:PWRK$DEFINE_COMMANDS.COM. To define these commands so that you can use them at login, refer to the Server Installation and Configuration Guide for your Advanced Server product.
    The PWSHOW command displays information about file server processes that are running on the system. The information is displayed in the same format that the SHOW SYSTEM command produces.
    The PWSHOW command accepts arguments to show processes on a specific node in a cluster and to show all nodes in a cluster as follows:
    • The PWSHOW CLUSTER command shows all file server processes running on each node in the OpenVMS Cluster.
    • The PWSHOW NODE nodename command shows the Advanced Server processes running on system nodename in the OpenVMS Cluster.

    This command is available after you invoke the PWRK$DEFINE_COMMANDS command procedure. To invoke this command procedure, enter the following command:


    @SYS$STARTUP:PWRK$DEFINE_COMMANDS.COM
    
  • Start the License Manager on a node that is not running the License Server and an error message states that the server is running on the nodename system. The License Manager must be run on the same node as the active License Server.
    For example, enter the command ADMIN/LICENSE. If the License Server is not running on that node, the message shown in Figure 3-1, License Server Startup Error Message, appears.

    Figure 3-1 License Server Startup Error Message


  • Look in PWRK$LOGS.
    The latest file that matches PWRK$LICENSE_SERVER_OpenVMS-cluster-name.LOG is produced by the active License Server and displays the message:


    License Server cluster-alias is now processing LAN Manager
    license requests on node active-node
    

    (The OpenVMS-cluster-name may not be a cluster name, although it most likely is one.)
    You use the TYPE or SEARCH commands to examine the file while it is still open.

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:

  • When the License Server is restarted.
  • Automatically, once every 24 hours, typically at 00:01 (system time). See Section 3.5.2, Scheduling the LMF Synchronization, for more information.
  • When requested by the License Manager for individual license types.

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