For more permanent access restrictions, issue one of the following commands:

• LICENSE DELETE
  Permanently deletes one or more licenses from a database, disallowing further license use. Use this command to eliminate terminated or unused licenses.
• LICENSE MOVE
  Automatically deletes a license as you reregister the license in another License Database.
  This command is similar in effect to LICENSE DELETE except that it also registers the license in the other database.

In an OpenVMS Cluster environment, you can control which nodes have access to a product. Some product licenses require you to control access by creating include or exclude lists with the LICENSE MODIFY command.

In an OpenVMS Cluster environment, license units are available to all nodes by default. If you need to control which nodes in a cluster have access to a product license, you must use the LICENSE MODIFY command with the /INCLUDE or /EXCLUDE qualifiers. These qualifiers take an argument list of System Communications Services (SCS) node names. SCS node names are system parameters set with the System Generation utility (SYSGEN). For example, if your cluster includes nodes MUSIC, ART, DANCE, and THEATR, you can specify that nodes MUSIC and ART have access to the software products registered in the License Database, while nodes DANCE and THEATR do not have access. The following command allows two nodes access to Pascal:

$ LICENSE MODIFY/INCLUDE=(MUSIC,ART) PASCAL

You can perform the same task by using the /EXCLUDE qualifier. The following command specifies the same product access as the previous command:

$ LICENSE MODIFY/EXCLUDE=(DANCE,THEATR) PASCAL

If a license does not provide enough license units for full availability across the cluster, use LICENSE MODIFY and one of these qualifiers. Otherwise, product availability is unpredictable. Products are authorized for use on nodes in the order in which they load the licenses. Unless you use an include list to control which nodes can load a product, the authorization to use a product can move from processor to processor during a series of system shutdowns and startups. When you shut down a system, LMF automatically unloads all loaded licenses on that system. If another cluster member boots before the first system reboots, the second system, referring to the common License Database, can automatically load the same license. Although this can be helpful, it may not be your intention.

You can use the /INCLUDE and /EXCLUDE qualifiers with the LICENSE MODIFY command to determine who has access to the pool of units created by LMF when it loads combinable licenses. However, note the following:

• LMF combines units from combinable licenses (licenses with the same product name and type) into a single pool from which all authorized nodes may draw. By default, all nodes are authorized. To restrict the nodes that are authorized, assign an include or exclude list to each license for the product.
• Adding the NO_SHARE option to PAKs prevents license units from being shared. You can use this option to reserve all the units on a PAK for a particular node in an OpenVMS Cluster.
• LMF unionizes all the include and exclude lists associated with combinable licenses. The resulting master list is all-inclusive; when combining licenses, a less restrictive list always overrides a more restrictive list.
• Assigning an include list to a license does not reserve the license units for the nodes in the list.

For example, if you assign an include list to four out of five combinable licenses, the default---all nodes are authorized---is in effect for the fifth license, and it overrides the lists on the other licenses. All nodes then have access to the product despite the include lists. Units for the product are allocated on a first-come, first-served basis as the nodes in the cluster are booted, until the pool of units is depleted.

To ensure access exactly as you intend it, assign the same include or exclude list to each license. Purchasing more license units to fulfill requirements to run across the cluster is another option.

5.6.2.1 Effect of the NO_SHARE Option

Some licenses, such as OpenVMS operating system licenses, have the NO_SHARE option; they cannot be shared in a cluster environment. If you are using a common License Database, you must register a separate license for each cluster node and modify each to establish which node can load it.

To ensure that LMF can load a NO_SHARE license in a cluster environment, you have two choices, as follows:

• When you register with VMSLICENSE.COM, you are prompted for a node name. Enter the correct SCS node name at the prompt.
• If you use LICENSE REGISTER, you must follow up by entering a LICENSE MODIFY/INCLUDE=node-name command.

A cluster environment typically uses a single License Database, which should include one OpenVMS license for each cluster node. You can change the association of license and node as long as the number, type, and size of the licenses match the processors present. For example, the cluster environment with nodes ART, MUSIC, DANCE, and THEATR should have four licenses, each one designated for a specific node. If you remove node THEATR and replace it with a node named CRAFTS, you must modify the license intended for THEATR to specify node CRAFTS.

Because an OpenVMS Cluster License Database often contains multiple licenses with the identical product name and producer, you should use the /AUTHORIZATION qualifier with LICENSE commands to uniquely identify a specific license. For example:

$ LICENSE MODIFY/INCLUDE=THEATR BASIC /AUTHORIZATION=USA123456 . . . $ LICENSE MODIFY/INCLUDE=CRAFTS COBOL %LICENSE-E-AMBIG, information provided was ambiguous; multiple licenses were found $ LICENSE MODIFY/INCLUDE=CRAFTS COBOL /AUTHORIZATION=USA123456

5.6.2.2 Editing Include and Exclude Lists

Each time you enter a LICENSE MODIFY command with an /INCLUDE or /EXCLUDE qualifier, LMF creates a new list. To edit an existing list, use the /ADD or /REMOVE qualifier in your command line. The following example illustrates the required syntax without using the /ADD or /REMOVE qualifier:

$ LICENSE MODIFY/INCLUDE=(ART,MUSIC,DANCE,THEATR) BASIC - _$ /AUTHORIZATION=USA123456 . . . $ LICENSE MODIFY/INCLUDE=(ART,MUSIC,DANCE,CRAFTS) BASIC - _$ /AUTHORIZATION=USA123456 $ LICENSE UNLOAD BASIC %LICENSE-I-LOADED, DEC BASIC was successfully loaded with 400 units

You can also use the following commands:

$ LICENSE MODIFY/INCLUDE=(ART,MUSIC,DANCE,THEATR) BASIC - _$ /AUTHORIZATION=USA123456 . . . $ LICENSE MODIFY/REMOVE/INCLUDE=(THEATR) BASIC /AUTHORIZATION=USA123456 $ LICENSE MODIFY/ADD/INCLUDE=(CRAFTS) BASIC /AUTHORIZATION=USA123456

If your license uses the MOD_UNITS option, you can also modify the size of a license in a cluster environment. To change the size of the license, enter a LICENSE MODIFY/UNITS=number command that specifies a number sufficient for your needs and allowed by your license agreement. For example, to change a license registered with 1000 license units to a 1500-unit license, enter:

$ LICENSE MODIFY/UNITS=1500 BASIC $ LICENSE LOAD BASIC

To control which users have access to a product, use the LICENSE MODIFY command with the /RESERVE qualifier. This qualifier takes an argument list of user names called the reservation list. Although the definition of a user can differ from product to product, most products accept the user name that OpenVMS maintains for each account. This is the name you type at the Username prompt during login. See your product's Software Product Description (SPD) for details.

If your PAK specifies the RESERVE_UNITS option, you must assign one or more users to a reservation list. The number of user names allowed per list depends on the number of activity units available. Calculate this number as you would for any activity license. For example, if a software product requires 50 license units per activity and your PAK provides 100 license units, you have a 2-activity license. If the PAK also specifies the RESERVE_UNITS option, you have an unlimited activity, two-user license. For this license, you must create a reservation list with at least one, but no more than two, names.

Example:
The following command assigns two users to a reservation list for the product called Terrapin:

$ LICENSE MODIFY /RESERVE=(R_HUNTER,J_BARLOW) TERRAPIN

Note that the LICENSE MODIFY command affects only data in the license database; it does not affect licenses already loaded. To change a loaded license, reload it with a LICENSE LOAD command. For example:

$ LICENSE MODIFY /RESERVE=(R_HUNTER,J_BARLOW) TERRAPIN $ LICENSE LOAD TERRAPIN %LICENSE-I-UNLOADED LICENSE-I-LOADED, DEC TERRAPIN was successfully loaded with 200 units

To add more user names to the reservation list, use the /ADD qualifier and the /RESERVE qualifier, as follows:

$ LICENSE MODIFY /ADD /RESERVE=(P_LESH,M_HART) TERRAPIN

This adds new users P_LESH and M_HART to any list already established for the specified product. You can remove a user name with the /REMOVE qualifier.

You can have many Personal Use Licenses for the same product. For license loading, LMF combines all of the license units and determines the number of users according to the total number of units. Therefore, the total number of names on combined reservation lists for this product must not exceed the number LMF authorizes from the unit count, because LMF authorizes only the correct number from the lists and rejects extra names.

Although you can find extra or repeated names using one or more LICENSE LIST/FULL commands, you cannot easily predict which users LMF will reject. Do not assume that LMF denies access to the third name listed on the reservation list of a two-user license. The total number of names and total number of license units is the important calculation.

To load corrections to a reservation list you must enter the LICENSE LOAD command for the licenses. The following example includes the warning message for too many names:

$ LICENSE MODIFY/RESERVE=(R_HUNTER,J_BARLOW) TERRAPIN $ LICENSE LOAD TERRAPIN LICENSE-I-LOADED, DEC TERRAPIN was successfully loaded with 200 units $ LICENSE MODIFY/ADD/RESERVE=(P_LESH,M_HART) TERRAPIN $ LICENSE LOAD TERRAPIN %LICENSE-I-UNLOADED LICENSE-W-LONGLIST, reserve list for DEC TERRAPIN exceeds maximum of 2, 2 names removed LICENSE-I-LOADED, DEC TERRAPIN was successfully loaded with 200 units

Because LMF combines the license units, you can assign one long reservation list to a single license; LMF simply adds the license units from the combinable licenses and counts the names in all reservation lists for those licenses. If you have three combinable licenses that authorize use to six users, you can modify one of them to have a 6-name reservation list. Note that this differs from the behavior of include and exclude lists with node names in an OpenVMS Cluster.

5.6.4 Controlling Loading Order

If you have many variations of licenses for a product (for example, with different versions, tokens, or hardware identifiers), and you think that you are not getting maximum use of the product, you can check the order of loading of the product licenses. By default, LMF assigns a selection weight to each license and loads each license in descending order of selection weight. The grant order is the order in which LMF checks licenses before granting one.

Loading is the process that LMF uses to store licenses in memory. Granting is the actual allocation of units to a user using a licensed product. Selection weights contol the order in which LMF checks multiple licenses for a single product while attempting to perform a license grant for that product.

To determine grant order, enter the DCL command SHOW LICENSE/FULL. You can then enter the LICENSE LIST command with the /SELECTION_WEIGHT qualifier to display the selection weight. Modify selection weights of licenses as needed with the /SELECTION_WEIGHT qualifier to the LICENSE MODIFY command.

To change the selection weight, use LICENSE MODIFY/SELECTION_WEIGHT, and then load the changed licenses with LICENSE LOAD.

5.7 Logical Name LMF$DISPLAY_OPCOM_MESSAGE

A previous version of this manual incorrectly stated that you must define the logical name LMF$DISPLAY_OPCOM_MESSAGE in order for messages to appear.

If you have already defined this logical name, you should delete the definition.

Define the LMF$DISPLAY_OPCOM_MESSAGE logical name only if you are explicitly directed by HP to do so (for debugging purposes). When defined, this logical name causes many "noise" messages to be displayed on the operator's console. Some of these messages can be confusing and misleading to the point of suggesting that a product is not licensed when in fact it is.

To see if this logical name has been defined on your system, enter the following command:

$ SHOW LOGICAL LMF$DISPLAY_OPCOM_MESSAGE

To delete the logical name, enter the following command:

$ DEASSIGN LMF$DISPLAY_OPCOM_MESSAGE/EXEC/SYSTEM

5.8 Troubleshooting Licensing Problems

If you are having problems that appear to be related to reaching PAK limits or missing licenses, you can perform basic troubleshooting using the LICENSE and SHOW LICENSE commands.

First, try listing the PAKs using the following command:

$ LICENSE LIST /FULL

This command will list all the PAKs that are in the License Database (.LDB) file. These licenses may or may not have been loaded into the memory license database. Check to make sure that all your active licenses have been loaded and that any unused licenses are not being loaded into the License Database.

Next, use the /HISTORY qualifier to check licensing activity.

$ LICENSE LIST /HISTORY

This command shows you all the activity you have performed to the License Database. Make sure that the history matches what you think should be.

You can also use the SHOW LICENSE command to see if the number of licenses is correct. The /UNIT_REQUIREMENTS command displays the information in the License Unit Requirement Table.

$ SHOW LICENSE /UNIT_REQUIREMENTS

Use the /CLUSTER qualifier to diplay the license unit requirements for every node in an OpenVMS cluster.

Use the SHOW LICENSE/USAGE command to see how many license units are loaded and how many are allocated and available. SHOW LICENSE/USAGE also tells you the license type for each product on the system.

If you own multiple license types for a single product in an OpenVMS cluster, you can only view the usage information for the license type loaded on the node from which you issued the SHOW LICENSE/USAGE command. To find out the usage of another license type loaded on another node, issue the command on that node.

In an OpenVMS Cluster, usage information is limited to the local license type. For example, LMF considers VAX and Alpha availability licenses different license types. If you are running both VAX and Alpha systems in a cluster, usage information for availability licenses is limited to the local system type. For example, if you have HP C installed on all nodes in your OpenVMS Cluster, you can display HP C license allocation on all the VAX nodes in the cluster from any VAX node with HP C installed, but you cannot display the HP C license allocation on the Alpha nodes.