License Management Utility Guide
- Operating System and Version:
- VSI OpenVMS IA-64 Version 8.4-1H1 or higher
VSI OpenVMS Alpha Version 8.4-2L1 or higher
Preface
The License Management Facility (LMF) is the software license management tool for the OpenVMS operating system. To run any software product on OpenVMS systems, you must register and load its license. To perform these tasks, use LMF.
1. About VSI
VMS Software, Inc. (VSI) is an independent software company licensed by Hewlett Packard Enterprise to develop and support the OpenVMS operating system.
2. Intended Audience
This guide is for managers of licenses for software products that run on the OpenVMS operating system. Typically, the system manager has this responsibility.
3. Document Structure
This guide is organized as follows:
Chapter 1 provides an introduction to the OpenVMS LMF and to the licensing of OpenVMS layered products.
Chapter 2 describes licensing requirements for OpenVMS Alpha and VAX systems.
Chapter 3 describes licensing requirements for OpenVMS I64 systems.
Chapter 4 describes each task required to manage software product licenses. This chapter also discusses LICENSE commands and shows how to use them.
Appendix A describes the syntax of the LICENSE commands.
Appendix B provides the difference between LICENSE LIST and SHOW LICENSE commands.
4. Related Documents
VSI OpenVMS System Manager's Manual
VSI OpenVMS System Management Utilities Reference Manual
VSI OpenVMS Record Management Utilities Reference Manual
VSI OpenVMS DCL Dictionary
Upgrade and installation manual for your version of OpenVMS software
The installation guides, release notes, and Software Product Descriptions (SPDs) for any software products you install
For additional information about VSI OpenVMS products and services, please visit
the VSI OpenVMS website at http://www.vmssoftware.com or contact us at
<info@vmssoftware.com>.
5. New and Changed Information in this Edition
The following information is new or revised for VSI OpenVMS I64 Version 8.4-1H1:
With this release, the VSI and HP Operating Environment (OE) names have changed. VSI and HP support two OEs:
The Base Operating Environment, containing the essential components required by all customers, including the OS, several layered products, networking options, languages, etc.
The High Availability Operating Environment, containing the Base Operating Environment plus additional components to support mission critical computing requirements, including VMS Clustering, Volume Shadowing, Reliable Transaction Router, etc.
For more information, see the VSI OpenVMS Version 8.4-1H1 Software Product Description (SPD).
Re-branding is ongoing and evident everywhere from documentation to licensing and the operating system itself. This is an iterative process that will take some time to sort out. Although VMS Software Inc. is an independent entity, our products remain closely tied to Hewlett Packard, therefore you will see a lot of both brands, VSI and HP. This is particularly evident in documentation and licensing.
Important
Although the VSI license facility and this manual indicate that both PPL and PCL license types are generated, both licenses types are implemented identically as per-core in the VSI License Management Facility and behave as expected..
6. VSI Encourages Your Comments
You may send comments or suggestions regarding this manual or any VSI document by sending electronic mail to the following Internet address: <docinfo@vmssoftware.com>. Users who have VSI OpenVMS support contracts through VSI can contact <support@vmssoftware.com> for help with this product.
7. OpenVMS Documentation
The full VSI OpenVMS documentation set can be found on the VMS Software Documentation webpage at https://docs.vmssoftware.com.
8. Typographical Conventions
The following conventions are used in this manual:
| Convention | Meaning |
|---|---|
| Ctrl/x | A sequence such as Ctrl/x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button. |
| PF1 x | A sequence such as PF1 x
indicates that you must first press and release the key labeled PF1
and then press and release another key
(x) or a pointing device button. |
... |
A horizontal ellipsis in examples indicates one of the
following possibilities:
|
. . . | A vertical ellipsis indicates the omission of items from a code example or command format; the items are omitted because they are not important to the topic being discussed. |
| ( ) |
In command format descriptions, parentheses indicate that you
must enclose choices in parentheses if you specify more than
one. In installation or upgrade examples, parentheses indicate
the possible answers to a prompt, such
as:
Is this correct? (Y/N) [Y] |
| [ ] |
In command format descriptions, brackets indicate optional
choices. You can choose one or more items or no items. Do not
type the brackets on the command line. However, you must include
the brackets in the syntax for directory specifications and for
a substring specification in an assignment statement. In
installation or upgrade examples, brackets indicate the default
answer to a prompt if you press Enter without entering a value,
as
in:
Is this correct? (Y/N) [Y] |
| | | In command format descriptions, vertical bars separate choices within brackets or braces. Within brackets, the choices are optional; within braces, at least one choice is required. Do not type the vertical bars on the command line. |
| { } | In command format descriptions, braces indicate required choices; you must choose at least one of the items listed. Do not type the braces on the command line. |
| bold type | Bold type represents the name of an argument, an attribute, or a reason. Bold type also represents the introduction of a new term. |
| italic type | Italic type indicates important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER=name), and in command parameters in text (where dd represents the predefined code for the device type). |
| UPPERCASE TYPE | Uppercase type indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege. |
Example |
This typeface indicates code examples, command examples, and interactive screen displays. In text, this type also identifies website addresses, UNIX command and pathnames, PC-based commands and folders, and certain elements of the C programming language. |
– | A hyphen at the end of a command format description, command line, or code line indicates that the command or statement continues on the following line. |
| numbers | All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes—binary, octal, or hexadecimal—are explicitly indicated. |
Chapter 1. Overview
This overview introduces the OpenVMS License Management Facility (LMF) and outlines the tasks required to manage software licenses for software products.
A product license protects the intellectual property of the software vendor and provides customers with access to the product. Product authorization is usually defined in a contract with specific terms and conditions agreed upon by the software license issuer and the software user.
License Management Facility and License Agreements
The terms and conditions of your license agreement determine your legal use of software. LMF is a management tool that can help you comply with your license agreement, but use of LMF does not indemnify you against noncompliance with the terms and conditions of your software license agreements. That is, LMF offers options for many kinds of license agreements, but use of some of these options might not authorize by your specific license agreement. Read your license carefully to determine which LMF options you can use legally.
1.1. License Management
Obtain a Product Authorization Key (PAK), which provides information required to register the license.
Use LMF to register the license in the License Database.
Use LMF to load the license from the License Database into memory.
Install the product specified by the PAK.
License Management utility (LICENSE) (see Section 1.2)
License Database (see Section 1.3)
1.2. License Management Utility (LICENSE)
The License Management utility (LICENSE) is the command line interface of the License Management Facility (LMF). Use LICENSE commands to interactively manage the licenses of OpenVMS layered software products and, in many cases, by third-party vendors.
LICENSE is a system-level tool that you use at the DCL prompt. LICENSE commands allow you to register licenses, load them into the License Database, and manage the licenses on your system. For information on using LICENSE commands, see Chapter 4. For reference information on commands, qualifiers, and examples, see Appendix A.
1.3. License Database
The License Database is a collection of information about each license on your system stored in a file on a disk. The default database file is SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB, which is created by LMF when you install the OpenVMS software.
Issuing LICENSE commands
Executing the VMSLICENSE.COM command procedure
In addition, LMF enters data and keeps records. The collection of data fields representing a license at any one time is called a record. When you first register a license, you create the first record with data specified in your PAK. If you later modify the license, LMF creates a new record to define the modified terms of the license, and includes a notation that the license was modified.
Figure 1.1 illustrates the relationship between LMF, the license units required for your system, and the License Database.
Chapter 2. Licensing on OpenVMS Alpha and OpenVMS VAX
This chapter describes licensing on OpenVMS Alpha and OpenVMS VAX systems.
On OpenVMS Alpha and VAX systems, the number of license units required are based on the rating of the system. LMF gets information about the units requirements from the console firmware. This information is contained in a License Unit Requirement Table (LURT).
Several different types of licenses are available on OpenVMS Alpha and VAX systems. In a cluster, these can be combined.
Section 2.1 describes how license unit requirements are computed.
Section 2.2 describes the types of licenses available.
Section 2.3 describes how licenses can be combined.
2.1. License Units and License Unit Requirement Tables
A license unit is a measurement of the authorization granted for use of a product. License units define the size of each license. Each license has a size, specified in license units. Each hardware system has a series of license unit requirements, also specified in license units.
The license unit requirements of a system are expressed in a rating. LMF stores ratings (in license units) for all available and appropriate Alpha and VAX systems in a called the License Unit Requirement Table (LURT). A LURT is associated with each category of software products as identified on the PAK. The PAK contains two fields, the Activity Table Code and the Availability Table Code, that include information to identify the category of the software product. Typically, systems that provide more performance have greater license unit requirements, but ratings can be unrelated to performance.
Alpha and VAX systems are classified into three levels by system class:
Enterprise system class
Department system class
Workgroup system class
Generally, the higher the system class, the larger the license must be to support the system.
The size of a software product license must be large enough to support the number of either users or processes using the product and the system on which the product is to run. LMF compares the size of a registered license to the rating of the current system and authorizes product use when a license supplies sufficient license units.
To locate the number of units required for your system, first find the system model number in the rating table. On Alpha systems, find the particular system configuration, which lists the number of processor cores. Then you can see the number of operating system units and layered product units required by your Alpha system. On VAX systems, only a single unit rating is used for both the operating system and layered products.
$ SHOW LICENSE/UNIT_REQUIREMENTS
LMF compares the size of a registered license to the license unit requirement for the system and authorizes product use when a license supplies sufficient license units.
- It looks for a code (A, B, C, D, E, F, G, H or I) or a keyword (CONSTANT integer) next to either the Availability Table Code field or the Activity Table Code field in the registered license.
If the license specifies CONSTANT and an integer value, LMF stops and defines the license unit requirement as equal to the stated integer value. This value could be the decimal value 0, which means the license has no unit limitations.
- If the license does not specify a constant unit requirement, LMF looks for a code that specifies license type and corresponds to a LURT. The codes and the types of licenses they represent as shown in Table 2.1.
Table 2.1. License Codes License Code License Type A VAX/VMS Capacity of OpenVMS Unlimited or Base B VAX/VMS F&A Server C VAX/VMS Concurrent User D VAX/VMS Workstation E VAX/VMS System Integrated Products F VAX Layered Products G Reserved H Alpha Layered Products I Layered Products
These codes and the units associated with them are shown when you issue a SHOW LICENSE /CHARGE_TABLE command.
Each LURT has a rating, in license units, for all available (and appropriate) hardware systems. For example, the LURT for layered products includes the name of every hardware model that can run OpenVMS and associates a number of license units with each. The LURT for OpenVMS workstations includes the names of all OpenVMS workstations and their ratings.
LMF determines the model name of your system by its System Marketing Model (SMM) name, which is the model name of a computer system used in marketing and pricing. The SMM is generally the name on the front panel of the system cabinet.
LMF locates the SMM in the appropriate LURT and selects the value that specifies the number of units required for the named SMM and type of license.
LMF compares the number selected from the LURT to the number of units registered for your product license. If you have registered a value sufficient for your license and system, the license is loaded successfully with the LICENSE LOAD command.
| System Model | Operating System Units | Layered Product Units |
|---|---|---|
| AlphaServer GS160 with 2 CPUs | 3000 | 1300 |
| AlphaServer GS80 with 1 CPU | 1000 | 1100 |
| AlphaServer ES45 with 2 CPUs | 100 | 1050 |
The number of license units registered with any license should match or exceed the number of license units required for the specified product to run on the specified system. For example, when you obtain a license for VSI Pascal to run on an AlphaServer ES45 system with 2 CPUs, that Pascal license must specify at least the same number of license units as the LURT requires for layered products on that system (1050 shown in Table 2.2). The same Pascal license may not provide enough license units to authorize use of Pascal on an AlphaServer GS160 system with 2 processors (1300 shown in Table 2.2). The size of the license to run a software product on an OpenVMS Cluster environment must reflect the total number of concurrent users or processes and the systems on which the product will run.
Not all licenses have a specific number of units. Some licenses specify zero units, which is equivalent to unlimited units.
2.2. Types of Licenses
| Type | Identification on PAK | License by | See |
|---|---|---|---|
| Availability | Availability Table Code has a nonzero value. | System type (Requires Key Option ALPHA or VAX_ALPHA to load on Alpha system.) | Section 2.2.1 |
| Activity | Activity Table Code has a nonzero value. | Concurrent uses (not users) | Section 2.2.2 |
| User | Activity constant and Key Options: USER. | Concurrent users (not uses) | Section 2.2.4 |
| Personal Use | Activity constant and Key Options: RESERVE_UNITS. | Named user | Section 2.2.3 |
The license descriptions that follow provide information to help you understand and manage the product authorization process on VAX or Alpha computers using LMF, rather than to help you order software licenses. VSI provides licenses in many ways that may not always correspond to the examples in this manual. Check with your VSI support representative for ordering information, and check the terms and conditions of your license contracts for restrictions.
2.2.1. Availability Licenses
An Availability License makes a product available to all the users of a system. LMF can load a product when there are sufficient license units available in the LMF to satisfy the unit requirements of all the nodes in the cluster which have already loaded the product and enough units remaining available to satisfy the unit requirements of the requesting node. To authorize full availability on a system, LMF checks the Availability Table Code on the registered license and interrogates the LURT to determine the rating of the system. If the registered license provides enough license units, LMF loads the license, making the product available to all users on the named system.
For example, the PAK for the fictional layered product ALLSUM provides 1000 license units (Number of Units: 1000) and refers to LURT F, (Availability Table Code: F). When you register and load the license, LMF selects LURT F and checks whether the size of the license is at least as big as the number of license units required by the current system. If so, LMF authorizes full availability to ALLSUM on the current system.
In addition to authorizing use on a system, LMF allocates the required number of units to the system that loads the license. If a 1000-unit Availability License is registered in a common OpenVMS Cluster environment License Database, LMF can allocate a total of 1000 license units among several nodes in the cluster. For example, LMF can allocate the 1000 units to one node that requires 500 units, one that requires 300, and a third that needs 200 license units. This is known as license sharing.
Note
You can load an availability license on an Alpha system only if the PAK contains either Key Option: ALPHA or Key Option: VAX_ALPHA. In addition, you can load a license authorized by a PAK with Key Option: ALPHA only on an Alpha system. However, the PAK can also safely reside in a License Database shared by both VAX and Alpha systems, and you can perform your License Database tasks from either a VAX or Alpha system.
2.2.1.1. Providing Sufficient License Units
The license you register in the License Database should provide enough license units to satisfy the requirements specified in the LURT. Before you purchase a license, work with your software representative to assess your software and hardware requirements to ensure that you obtain a license of the correct size.
For standalone systems (including multiprocessors), VSI offers licenses that exactly match the license requirements of a system. That is, there is a license size that matches each LURT entry.
Note
If your license specifies the /MOD_UNITS option, you can increase the number of units of the license (see Section 4.6.2). You can always decrease the number of license units, even if your PAK does not specify the MOD_UNITS option.
2.2.1.2. Providing More License Units
You may need to provide more license units than are currently registered in the License Database for a product. For example, you cannot load a 400-unit license on a system that requires 700 units. If you need more license units than are currently available, contact your software representative, who may recommend one of the following:
A new license that provides all the required license units. This may involve deleting the current license (with the LICENSE DELETE command).
Another license for the same product that provides 300 additional license units. If your license agreement allows it, you can register both licenses. LMF may combine the license units to produce the equivalent of a 700-unit license. For a description of license combination, see Section 2.3.
A different type of license. Some products offer Activity, Availability, Personal Use, and User licenses. Changing to a different type of license may provide greater access to the product.
2.2.1.3. Providing Availability in an OpenVMS Cluster Environment
In an OpenVMS Cluster environment, you must consider all of the nodes that can load a product. To provide full availability for a product in an OpenVMS cluster environment with a common License Database, you must register licenses with a total number of license units at least as large as the total license unit requirements of all the nodes. For example, if the cluster consists of three VAX 8800 systems, each of which requires 1200 license units to run a specific product, you must register at least 3600 license units (1200 times 3) to provide full product availability across the cluster environment. Each node in the cluster will load 3600 units.
Why does each node in a cluster load all 3600 license units if it only uses 1200?
Think of the 3600 license units as a cluster-wide pool made up of the requirements of each of the nodes. Loading a license is like joining the pool: each node must be aware of the total size of the pool, the existing split, and its own requirements.
Assume that you have a three-node cluster, ALPHABET. ALPHABET consists of the nodes A, B, and C, which boot in that order whenever the cluster is rebooted. Also assume that ALPHABET has an Availability PAK and a valid LDB configured with 3600 units available. When node A boots, it sees 3600 license units. No other nodes are online, so it loads 3600 units and allocates 1200 of the units for itself.
Node B boots up and sees 3600 units registered and that A is using 1200 of the units. The remaining 2400 units is larger than the 1200 the node requires. Node B loads 3600 units and allocates 1200 for itself.
Node C boots up and sees 3600 license units registered. Nodes A and B have each allocated 1200 units, leaving a remainder of 1200, which is enough for Node C. Node C loads 3600 units and allocates 1200 for itself.
If you do not need product availability clusterwide, you can register licenses with total license units to authorize use by individual nodes. For example, in a cluster with three nodes each requiring 1200 license units, a 1200-unit license allows any one node to run the product, and a 2400-unit license allows any two cluster nodes to run the product concurrently. You can also use the LICENSE MODIFY command to allow or deny access to specific cluster nodes (see Section 4.6.2).
For example, suppose that on the ALPHABET cluster, you only want nodes A and C to use the product. You only need 2400 license units. The way to insure that only A and C can use the product is to place an INCLUDE or EXCLUDE list on all PAKs for that product.
$ LICENSE MODIFY product /ALL/INCLUDE=(A,C)
$ LICENSE MODIFY product /ALL/EXCLUDE=(B)
Without the LICENSE MODIFY /INCLUDE or /EXCLUDE command, the first node to boot would find and load 2400 license units. The second node would find 2400 license units, note that another node is already using 1200 units and that the remainder, 1200 units, is sufficient to satisfy its requirements and load the entire 2400 units. The third node would also try to load the product, realize all the license units are already in use and fail.
Note that you cannot always manage licenses as previously described. For example, some licenses restrict a product to a certain system type, and other licenses with the NO_SHARE option cannot share license units. As always, check the terms and conditions of your license contract.
2.2.1.4. Providing More Availability
If you change the configuration of an OpenVMS Cluster by adding a node, or upgrading an existing node to a more powerful one, you may need to increase the number of available license units. You can provide more license units in the following ways:
Register additional licenses.
If you choose to register an additional license (sometimes referred to as an additive PAK), you gain flexibility; the new license can be moved to different cluster environments or standalone systems independently. When you register the new license, LMF automatically combines the license size of the new license with the license size of the existing license to establish a new, higher level of license authorization. Management of separate licenses for the same product can be more complicated, however.
Replace the current license with a larger one.
A new license with more license units (sometimes referred to as a replacement PAK), is easier to manage but is not as flexible, because it cannot be split among different cluster environments or standalone systems. You typically delete or disable the older license, then register the new one.
Your software representative can help you choose the option that fits your needs.
2.2.2. Activity License
An Activity License defines the number of concurrent uses allowed for a product at any one time. Each product defines an activity as either an interactive user, a running process, volume shadowing, or a job. For example, when you register a 4-Activity License, LMF authorizes four concurrent uses of the product. Each time an activity invokes the product, LMF checks whether there are sufficient license units available to use the product on the current system, and if so, allocates the license units to that activity, reducing the number available to additional activities. When all license units are allocated, no new activity can invoke the product until an activity terminates use of the product (thereby deallocating license units).
As with an Availability License, an Activity License authorizes use through license units and LURTs. A product may require a certain number of license units per activity, regardless of the hardware system. For example, a 4-Activity License for a product that requires 100 license units per activity has a size of 400 license units, and allows up to four activities, whether on a MicroVAX system or a VAX 8800 system. The license unit requirement of the product is designated on the PAK as Activity Table Code: Constant=100 .
Other products require a certain number of license units per activity on a particular system. A 4-Activity License for a product that requires 100 license units per activity on a VAX 8800 system requires 400 license units. The same 100-unit license provides five concurrent uses on a system that requires only 75 units per activity (of that product).
One primary difference between an Availability License and an Activity License is the time at which LMF checks the number of license units authorized by a license, as follows:
The Availability License allows unlimited access to the product after you successfully load the license on a system.
The Activity License requires allocating available license units each time the product is invoked, and denies access when the activity limit is reached.
2.2.2.1. Providing Enough License Units
As with Availability Licenses, you should try to match system, product, and license to your user requirements. Software vendors offer a variety of licenses that can match the license requirements of your users and your system. Before you obtain a product license, consult your software representative to define your software and hardware requirements to ensure that you obtain a license of the correct size.
The license you register in the License Database should provide enough license units to allow a predetermined number of activities access to the product. For example, if a software product requires 25 license units per activity on your system and PAKs come in 4-activity increments, the license you register should provide at least 100 units. Note that a 120-unit license provides no more use than a 100-unit license on such a system.
Different systems can have different license unit requirements per activity. Therefore, the number of users authorized by a license varies according to the system. For example, you may manage the following standalone systems:
VAXBIG, which requires 25 license units per activity to authorize a product
VAXMID, which requires 20 license units per activity to authorize a product
If you obtain a 125-unit Activity License for VAXBIG, you can temporarily move that license (with the LICENSE COPY command) to VAXMID when you shut down VAXBIG for maintenance. The 125-unit license, which allows 5 concurrent activities on VAXBIG, provides 6 concurrent activities on VAXMID. Note that you can also move an 80-unit (4-Activity) license originally intended for VAXMID to VAXBIG. However, on VAXBIG, the license provides access to only 3 activities.
As with Availability Licenses, you can register a license in the License Database even if that license cannot be successfully loaded. For example, if you register a 40-unit license that provides product access to two activities on a MicroVAX A system, the same license does not allow access to any activities on a system that requires 50 units per activity.
2.2.2.2. Determining Your License Needs
-LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
Analyzing the frequency of these messages can help you determine your license needs. If you need additional Activity License units, contact your VSI support representative, who may recommend one of the following:
A new license that provides all the required license units. This may involve deleting the current license (with the LICENSE DELETE command).
Another license for the same product that provides additional license units. If the terms of your license agreement allow it, you can register both licenses. This allows LMF to combine the license units, providing more product use. For a description of license combination, see Section 2.3
A different type of license. Some products offer Activity, Availability, Personal Use, and User licenses. Changing to a different type of license may provide greater access to the product.
2.2.2.3. Sharing License Units in an OpenVMS Cluster Environment
All cluster activities can access a product that has an Activity License registered in the common License Database. If your PAK specifies a constant number of license units per activity regardless of the system size, the cluster always provides access to the same number of activities. A 4-Activity License provides access to 4 activities whether the cluster has 1 node or 12 nodes, 1 MicroVAX system or 12 VAX 9000 systems.
In other cases, an Activity License may not specify a constant number of license units per activity on all nodes. Because the Activity License unit requirement can be different on each node in the cluster, the number of available activities depends on the system class of nodes involved.
For example, a particular Activity License might provide access to any 12 activities for a product on an OpenVMS Cluster with three VAX 8200 systems. If you add a node to the cluster that has a higher license unit requirement (than a VAX 8200), the number of concurrent uses allowed can decrease, because LMF allocates more license units per activity of the product on the additional node. You can modify the Activity License (using the LICENSE MODIFY command) to include or exclude specific nodes.
Note also that when the system starts up, LMF, by default, loads any licenses that do not have include or exclude lists. To control license loading, limit access with a LICENSE MODIFY/EXCLUDE or LICENSE MODIFY/INCLUDE command for each license that can be combined when licenses are loaded.
2.2.3. Personal Use License
A Personal Use License designates the names of specific users for unlimited use of a product. Before you load the license, you specify the users allowed access. LMF adds these users to a reservation list, which is checked before granting access to each user who tries to invoke the product. A PAK for a Personal Use License specifies RESERVE_UNITS in the Key Options field. This license shares some characteristics with both the Availability and Activity Licenses.
Although a personal use PAK includes an Activity Table Code, it does not limit access to concurrent use. While an Availability License authorizes product use by system, a Personal Use License authorizes product use by user name. LMF processes a list of authorized users when the license is loaded. After the license is loaded, any user on the list can access the product.
To calculate the allowed number of names on the reservation list, LMF divides the number of license units by the constant value listed in the Activity Table Code field of the PAK. If you register a 400-unit Personal Use License with a constant value of 100, LMF authorizes four specifically named users to access the product. If more than four names are associated with the license, LMF rejects extra names from the reservation list and denies access when those users attempt to access the product.
Personal Use Licenses are subject to combination rules that allow long lists of authorized users. See Section 2.3 for information about combining Personal Use Licenses.
Each Personal Use License must have an associated reservation list that specifies the name of each user with authorized access to the product. You cannot load a Personal Use License that does not have an associated reservation list with at least one user name. See Section 4.6.3 for information about controlling access to licenses with reservation lists using the LICENSE MODIFY command.
2.2.4. User License
The User License shares some characteristics with the Activity and Personal Use Licenses, as follows:
Each user is counted once towards the total number of concurrent users allowed. The terms of your license determine that total number.
Each user granted access has unlimited access to the product until exiting the last invocation, but is counted against the authorized limit only once.
Once the user has exited the last invocation of the product, renewed access will be denied if the total number of users of the product has reached the maximum authorized by the license.
2.2.5. Group License
A Group License authorizes access to a group of software products—usually related—that are licensed as one product. This enables you to license a group of products by registering only one PAK. A Group License can be any type of license: Availability, Activity, Personal Use, or User License.
All LICENSE commands use the group name for the product-name parameter instead of the individual product names. For example, a Software Group called COMPILER_1 might include VSI Fortran, VSI Pascal, and VSI COBOL. You register the Group License as COMPILER_1 with one PAK and enter all LICENSE commands using COMPILER_1 as well.
Group PAKs do not look different from single product PAKs. For information about the products licensed by a group PAK, see the Software Product Description (SPD) for the group product.
2.3. License Combination
License combination allows LMF to create large licenses by adding together the license units of multiple licenses. For example, two 50-unit Availability Licenses become equal to one 100-unit Availability License. Ten 100-unit Personal Use Licenses become equal to one 1000-unit Personal Use License.
License combination and loading are controlled by both the terms of your PAK and options you set with the LICENSE MODIFY/COMBINE and LICENSE MODIFY/NOCOMBINE commands.
LMF automatically combines some licenses by default.
2.3.1. Licenses That can be Combined
When a system loads a license, LMF scans the License Database for all combinable licenses and makes a pool of license units available for use. Licenses are combinable if they have matching data in each of the following data fields:
Product name
Producer
Availability
Activity
Key Options: RESERVE_UNITS, USER, NO_SHARE (assigned node must match), ALPHA, or VAX_ALPHA
Product Token
Hardware-ID
VAX Availability, ALPHA Availability, VAX_ALPHA Availability, User, Activity, and Personal Use licenses are different types of licenses. Therefore, they do not combine.
LMF matches any two empty data fields and, in the Availability and Activity fields, also matches the entry CONSTANT=0 with an empty data field. Licenses with the NO_SHARE option can combine, but they must have matching include lists that assign each license to the same node. This is the only time either an include list or an exclude list has an effect on license combination.
By default, LMF does not automatically combine otherwise combinable licenses if any one of the following attributes do not match:
Termination Date
Release Date
Version
Reservation List
LICENSE MODIFY product-name /COMBINE
2.3.2. Include, Exclude, and Reservation Lists
If you register a combinable license without an include or exclude list, any system can load the license with access to the entire pool of combined license units, with the following results:
The entire pool of Availability License units becomes available to the system that loads the license. LMF allocates the number of license units required for each system as it loads the license. The appropriate LURT defines this number.
The entire pool of Activity License units can be available to any user (or activity) that loads the product. LMF allocates the license units as each user accesses the product.
By default, when combining Activity Licenses, LMF combines those without reservation lists into one license without a reservation list, and those with reservations lists into one license with a reservation list that combines the separate reservation lists.
By default, when combining User Licenses, LMF combines those without reservation lists into one User License without a reservation list, and those with reservations lists into one User License with a reservation list that combines the separate reservation lists.
By default, when combining Personal Use Licenses, LMF combines any reservation lists associated with each license into one large reservation list that applies to all the combined licenses.
2.3.3. Termination Dates and Version Numbers
| License 1 | License 1 | Combined License | |
|---|---|---|---|
| Version Number | 2.3 | 2.0 | 2.0 |
| Release Date | 1-JAN-2005 | 30-NOV-2005 | 1-JAN-1995 |
| Termination Date | 1-JAN-2008 | 30-SEP-2005 | 30-SEP-2005 |
Chapter 3. Licensing on OpenVMS I64
Operating Environment and Tiering (see Section 3.1)
License types (see Section 3.2)
Compliance checking and reporting (see Section 3.3)
3.1. Operating Environment and Tiering
Base Operating Environment (BOE)
This OE includes the base operating system plus networking transport, internet capability, and other basic functions.
High Availability Operating Environment (HAOE)
The HAOE contains everything in the BOE plus additional system management capability, volume shadowing, clustering and other advanced capabilities.
OPENVMS-I64-BOE
OPENVMS-I64-HAOE
The operating environment license grants use of all products within the OE. Additionally, some components of the OEs (like clustering, which is part of the HAOE) are available individually. For example, you can add a cluster license to the base operating environment. The combination of OE tiering and the ability to add individual components allows you to tailor your environment to best meet your needs.
Information on the products contained in each operating environment is stored in a datafile (LMF$OE.DAT). The contents of the datafile are loaded into memory when the system is booted. Over time, the contents of the various OEs may change or new OEs may be offered by VSI. When that occurs, VSI will provide a new LMF$OE.DAT datafile that contains information on the new or changed OEs. You can use the LICENSE LOAD/OEDB command to update the OE database on your system with the new information. Consult the current Operating Environment Software Product Description for information on the contents of all available operating environments and their contents.
Once you have registered your PAK and loaded your OE license, you can see information about the available operating environments, the hierarchy among them, and the products contained in each OE by using the following command:
$ SHOW LICENSE/HIERARCHY/FULL
Operating Environment Hierarchy
-------------------------------
--------- Operating Environment ---------- ------ Units ------
Name Description Type Level Loaded Total
HAOE High Availability H 5 0 0
GWLM
MCOE Mission Critical H 4 - 0
RTR-SVR
VMSCLUSTER
VMSCLUSTER-CLIENT
EOE Enterprise H 3 - 0
AVAIL-MAN
RMSJNL
VOLSHAD
BOE Base H 2 - 0
DECRAM
OMS
FOE Foundation H 1 - 0
OPENVMS-I64
OPENVMS-USER
DVNETEND
DW-MOTIF
UCX
TDC
X500-ADMIN-FACILITY
X500-DIRECTORY-SERVER
CIFS
The example lists each OE and its contents in a hierarchical fashion so that the products contained in each OE are identified. The display also shows the number of units loaded.
To see the contents of a single OE, for example HAOE, use the following command:
$ SHOW LICENSE/OE=HAOE/FULL Current Operating Environment on node GAFFER at 27-APR-2015 20:27:31.95: --------- Operating Environment ---------- ------ Units ------ Name Description Type Level Loaded Total HAOE High Availability H 5 0 0 GWLM RTR-SVR VMSCLUSTER VMSCLUSTER-CLIENT AVAIL-MAN RMSJNL VOLSHAD DECRAM OMS OPENVMS-I64 OPENVMS-USER DVNETEND DW-MOTIF UCX TDC X500-ADMIN-FACILITY X500-DIRECTORY-SERVER CIFS
This example shows all products within the HAOE without distinguishing between operating environment hierarchies. All products contained in BOE and HAOE are listed together.
You can upgrade or downgrade your OE without a reboot using LMF. For example, you may want to change the number of processor cores on a system, change the OE available on a particular node, or move a license to another node. Any of these actions may require upgrading or downgrading your OE. This flexibility allows you to make maximum use of the products for which you are licensed. To upgrade to a higher OE tier or to add license units, register and load the new license into the database using the LICENSE REGISTER and LICENSE LOAD commands. To downgrade, use the LICENSE UNLOAD command.
3.2. License Types
Per core licenses (PCL)
Activity licenses
3.2.1. Per Core Licenses
An Integrity-specific license type, per core license (PCL), implements the licensing model on OpenVMS I64 systems and is based on the number of active processor cores on the system. Each active processor core requires one PCL unit. If you increase or decrease the number of active processor cores on a system, the requirement for PCL licenses changes.
A PCL license is required to run operating environments, OE products purchased separately (like clustering), and many standalone products on OpenVMS I64 systems.
PCL licenses offer flexibility as you can purchase licenses in the exact number you need and you can move the licenses to other processors. If you upgrade or reconfigure your system with additional processor cores, you purchase additional PCL licenses.
LMF constantly checks the number of PCL licenses against the number of active processor cores and enforces a soft compliance model described in Section 3.3.3. Any changes to the system are noted and checked for compliance.
Note
You will continue to see references to PPL in the PAKs and when using the LICENSE commands; however, the licenses will be managed as if they are the PCL license type.
3.2.2. Activity Licenses
For layered products such as compilers, activity licenses like those on Alpha and VAX systems are used. The units for these products are expressed in multiples of 1, rather than the 100s as on Alpha and VAX. A sample PAK for C might look like the following:
ISSUER: VSI AUTHORIZATION NUMBER: USA126087 PRODUCT NAME: C PRODUCER: VSI NUMBER OF UNITS: 3 VERSION: PRODUCT RELEASE DATE: KEY TERMINATION DATE: 31-DEC-2014 AVAILABILITY TABLE CODE: ACTIVITY TABLE CODE: CONSTANT=1 KEY OPTIONS: MOD_UNITS PRODUCT TOKEN: HARDWARE I.D.: CHECKSUM: 1-BGON-IAMA-LEEH-EPEL
In this example, up to 3 users are licensed to use the C compiler concurrently. If a fourth user attempts to use the C compiler, that user receives the following message:
-LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
LMF will not allow the fourth user access to the C compiler. This behavior is identical to that on OpenVMS Alpha and VAX systems.
3.3. Compliance Reporting
Hardware compliance—checks license against hardware system rating
Soft compliance—checks number of PCL licenses against the number of active processor cores
3.3.1. Hardware Compliance
To run an operating environment on an I64 system, you must have a license appropriate for your system rating based on sockets. A socket is a recepticle into which a processor module can be installed. Each processor module can contain one or more processor cores. Your PAK for an I64 system may have an entry in the HARDWARE_ID field (expressed as SOCKETS=n). For example, if your PAK has the entry SOCKETS=4 in the HARDWARE_ID field, you can load that license on a 1, 2, 3 or 4-socket system. If you try to load a license for a 2-socket system on a 4-socket system, the license will not load. In this case, LMF is enforcing a hard compliance check.
You can check the number of sockets on a system by using the following command:
$ SHOW LICENSE /CHARGE_TABLE OpenVMS I64/LMF Charge Information for node ADI26B This is an rx2600 (900MHz/1.5MB), with 2 cores active Type: PPL, Units Required: 2 (I64 Per Processor) Type: PCL, Units Required: 2 (I64 Per Core)
This example shows that node ADI26B has 2 sockets. Also, note that the example displays both the PPL and PCL types, because of the number of licenses sold.
You can buy a license for an unlimited number of sockets. In that case, there is no keyword specified in the HARDWARE_ID field.
To ensure hardware compliance, add an include or exclude list to your licenses by using the /INCLUDE or /EXCLUDE parameter to the /HARDWARE_ID=SOCKET tag. For example, if you are using a common License Database in a cluster with one Integrity rx4640 server (4 sockets), two Integrity rx2620 servers (2 sockets), and one Integrity rx8620 server (16 sockets), verify that the units in the 16-socket license are used only on the rx8620. For a description of adding an include or exclude list to a license, see the LICENSE MODIFY command in Appendix A.
3.3.2. Soft Compliance
In addition to having a license appropriate for your system hardware rating, you must also have a per core license (PCL) for each active processor core. The PCL units for I64 systems are in units of 1 per processor core.
To assist you in maintaining the terms and conditions of your licensing agreement, VSI provides a reporting mechanism that flags noncompliance for per core licenses. For example, if you load a license with only 2 units onto a system with 4 active processor cores, the license will load but a message indicating that the system is out of compliance is logged to the OPCOM facility and a mail message is sent to the SYSTEM account. You can bring this system back into compliance in two ways: load a license with 2 additional units or deactivate 2 of the 4 processor cores.
This soft compliance mechanism gives you flexibility to alter your system configuration temporarily and reminds you that you need additional per processor licenses to run in a compliant mode. LMF checks for compliance periodically and continues to log messages to the OPCOM facility and send mail to the SYSTEM account at predetermined intervals until sufficient PCL units are loaded on to the system to bring it into compliance.
Vendors who utilize LMF to manage their product licensing may choose to use a hard compliance model. If a vendor wants to enforce hard compliance, they can generate a PAK with the keyword HARD_COMPLIANCE in the OPTIONS field. Under a hard compliance policy, the license will not load and a user cannot run the application if they do not have a sufficient number of PCL units for each active processor core.
3.3.3. Sample License Checks
The following examples show how LMF combines checking the hardware rating and the PCL licensing requirements for OpenVMS I64 systems. An rx2600 is a 2-socket system and each socket can accept only a single-processor core module. Hence, the maximum number of processors on an rx2600 is 2. A PAK for a Base Operating Environment on this system might look like the following:
ISSUER: VSI AUTHORIZATION NUMBER: USA126087 PRODUCT NAME: OPENVMS-I64-BOE PRODUCER: VSI NUMBER OF UNITS: 1 VERSION: PRODUCT RELEASE DATE: KEY TERMINATION DATE: 31-DEC-2014 AVAILABILITY TABLE CODE: ACTIVITY TABLE CODE: KEY OPTIONS: PRODUCT TOKEN: HARDWARE I.D.: SOCKETS=2 CHECKSUM: 1-BGON-IAMA-GNOL-AIKO
The example shows the maximum number of sockets for this system as 2, as specified by the SOCKETS=2 keyword listed in the HARDWARE_ID field. This license could be loaded on any system with 1 or 2 sockets. The number of processor cores authorized to run the Base Operating Environment by this per processor license is 1, as specified in the NUMBER OF UNITS field. If you wanted to add another processor, you would need to purchase an additional PCL.
An rx4640 system is a 4-socket system and each socket can accept either a single-processor core or a dual-processor core module. This system may have up to 8 processor cores, depending on how it is configured. A PAK for the Base Operating Environment on this system might look like the following:
ISSUER: VSI AUTHORIZATION NUMBER: USA126087 PRODUCT NAME: OPENVMS-I64-BOE PRODUCER: VSI NUMBER OF UNITS: 2 VERSION: PRODUCT RELEASE DATE: KEY TERMINATION DATE: 31-DEC-2014 AVAILABILITY TABLE CODE: ACTIVITY TABLE CODE: KEY OPTIONS: PRODUCT TOKEN: HARDWARE I.D.: SOCKETS=4 CHECKSUM: 1-BGON-IAMA-GNOL-AIKO
The example shows the maximum number of sockets for this system as 4, as specified by the SOCKETS=4 keyword in the HARDWARE_ID field. This license could be loaded on any system with 1 to 4 sockets. The number of processor cores authorized to run the Base Operating Environment by this license is 2, as specified in the NUMBER OF UNITS field. If you wanted to add more processor cores, you would need to purchase additional PCL units.
Chapter 4. Using LMF
This chapter provides details about the tasks involved in managing software licenses. Topics covered include:
Overview for License Registration (see Section 4.1)
Managing the License Database (see Section 4.2)
Getting a Product Authorization Key (PAK) (see Section 4.3)
Registering licenses (see Section 4.4)
Loading a license (see Section 4.5)
Managing licenses after registration (see Section 4.6)
Using logical name LMF$DISPLAY_OPCOM_MESSAGE (see Section 4.7)
4.1. Overview for License Registration
The following four steps outline the minimum process to license and use software products on the OpenVMS operating system. The following sections describe in detail how to accomplish these steps.
Obtain a PAK for your product.
This is usually a hardcopy or electronic document containing information similar to that shown in Example 4.1. Order it from the software license issuer or software product producer.
Register information from the PAK into the License Database.
Use command procedure VMSLICENSE.COM to prompt for license registration information or enter the LICENSE REGISTER command directly. The example in this section, produced with a LICENSE LIST command, shows a license registered in the License Database. In this manual, the PAK information registered in the License Database is called a license.
Ensure that the system loads the registered license.
LMF requires that a registered license be loaded before you can use the product. When you register a license with VMSLICENSE.COM, you can confirm an option to load the license automatically. If you register a license with the LICENSE REGISTER command, you must also load it with a LICENSE LOAD command in order to use the product. At system startup, LMF automatically loads registered licenses.
Install the product that corresponds to the license.
Although the terms and conditions of license contracts vary, generally a license correlates with a particular release of a product. Because there are multiple factors that can affect the use of a license, such as the product release date, a version check, or a termination date, and because LMF allows products to check the License Database for properly registered licenses, you must match the license to the product.
After performing these steps, you can modify the license for a system or involve multiple systems in a licensing scheme (if your license agreement allows it).
For example, you want to restrict a license used in an OpenVMS Cluster environment to a specific node. If you register a license that uses the NO_SHARE option (for example, an OpenVMS operating system license), assign the license to a specific node. Either enter a LICENSE MODIFY/INCLUDE=node-name command or respond to the prompt for a System Communications Services (SCS) node name in VMSLICENSE.COM (see Section 4.4.4 for details).
4.2. Managing the License Database
LMF stores all information about licenses in the License Database. By default, LICENSE commands refer to the default License Database, and you usually do not need to know the name and location of the database. However, for system management reasons, you may need to move the database. This section describes techniques for accessing license information and moving the License Database.
Most of the data fields in the License Database correspond to either the LICENSE qualifiers or to responses to command procedure prompts. For example, the authorization field contains the data entered with the following command:
$ LICENSE REGISTER /AUTHORIZATION=string product-name
If you enter USA1234 for the string, USA1234 becomes the data in that field.
When you first register a license, you create the first record with data matching your PAK. When you enter other LICENSE commands, LMF creates new records to include any changes you make. For example, when you enter a LICENSE MODIFY command, LMF creates a new record marked with the new information, including a notation that the license was modified.
For performance reasons, License the Database information is duplicated in memory while your system is running. LICENSE commands impact the database stored on disk. To update the License Database information in memory, use the LICENSE LOAD or LICENSE UNLOAD commands.
4.2.1. The License Database Location
If you move the License Database to another directory or disk, or rename the database file, you must either define the logical name LMF$LICENSE at the system level to point to the new database, or you must use the /DATABASE=filespec qualifier with all LICENSE commands.
Place permanent systemwide logical name definitions in the file SYS$COMMON:[SYSMGR]SYSLOGICALS.COM.
If you have multiple system disks in an OpenVMS Cluster environment where all the systems can access one of the system disks, put your common License Database on the readable disk. For any systems that boot from a separate system disk, you must redirect LMF to the License Database. Define the logical name LMF$LICENSE to be the disk where the database exists.
If you have multiple system disks in an OpenVMS Cluster environment where some systems cannot access one of the system disks, you must keep separate identical License Databases. Whenever one database is modified, you must copy it to update the other databases.
VSI recommends you back up the License Databases after every modification.
4.2.2. History Records
License record before modification
LICENSE command used to modify the record
Date and time of modification
The history record also logs the username of the person who made the changes to the PAK.
History records accumulate over time and provide a comprehensive audit trail of all modifications you make to the License Database. Most software issuers, including VSI, require that you retain this information to demonstrate that you are complying with license terms and conditions.
To display history information, enter the following command:
$ LICENSE LIST /HISTORY
To create a hard copy, enter the following command:
$ LICENSE LIST /HISTORY /OUTPUT=LICENSE.LIS $ PRINT LICENSE.LIS
Over time, LICENSE commands, including the LICENSE START command issued automatically during system startup, might take longer than usual to execute. This could be due to an accumulation of license history records in the License Database.
If you notice delays, VSI recommends that you purge the history records in your active License Databases, but only after first preserving this information in one or more backup locations. Use the DCL command COPY or the Backup utility to make a copy of the License Database, thereby preserving the current version of the License Database, including history records.
To purge history records, enter the following command:
$ LICENSE DELETE /STATUS=EXTINCT *
Caution
Ensure that you do not omit the /STATUS=EXTINCT qualifier in the above command. If you do, all license records are deleted, leaving your License Database empty.
LICENSE DELETE deletes all history records, making them invisible to subsequent LICENSE commands.
Creating a new, compressed version of the License Database reclaims the disk space formerly occupied by the now deleted history records. To create a compressed License Database, use the DCL Convert utility (CONVERT).
4.3. Getting a Product Authorization Key (PAK)
Generally, you obtain both a PAK and the product from a representative of a company that distributes software. You order a PAK just as you order another product from VSI or another company. LMF needs specific values from a PAK to identify the source of the PAK and the source of a product.
A PAK comes from a PAK issuer—the LMF name for the entity that supplies the PAK. Licenses from VSI for I64 systems specify VSI for the PAK issuer. Other software vendors provide their own PAK issuer strings with their licenses. LMF uses the string to differentiate between different sources of licenses.
VSI may distribute and issue a PAK for a product that it does not produce. Thus, LMF also uses a string that identifies a software producer. A producer is the company that supplies the software product. Generally, a producer and a PAK issuer are the same. The current default producer name when you register a PAK with VMSLICENSE.COM or the LICENSE REGISTER command is VSI.
The OpenVMS operating system and LMF use PAKs to authorize most products for use. For example, after you install OpenVMS, you may have all the software required to use the System Integrated Products (SIPs) such as networking, RMS Journaling, and Volume Shadowing, but not be authorized to use any of them. To enable a SIP, register its PAK and load the license (there is no separate installation media). Even when you receive multiple software products in a single installation kit, you must register and load a PAK for each product to enable the software for use.
Some products follow the older product distribution and license approach, providing installation kits that include distribution media and documentation. If a kit does not include the PAK, order it separately.
Figure 4.1 illustrates the PAK transfer process.
4.4. Registering Licenses
To run most software products, including the OpenVMS operating system, you must first register the product license in the License Database and then load the registered license. In addition, many third-party vendors of OpenVMS layered software also require you to use LMF to complete the same licensing tasks for their products.
The following figure describes the registration options and presents examples of registration.
The following figure illustrates the routes from a PAK to the License Database.
4.4.1. When To Perform Registration
Most VSI software that runs on OpenVMS systems and many third-party software layered products use LMF. To check a product’s licensing requirements, see its installation manual or release notes. These documents explain which products use LMF registration.
If a product uses LMF, you must obtain a PAK, which includes the appropriate data for you to enter. The following example shows a typical PAK.
Issuer: VSI Authorization: USA12345 Product Name: CRYPTICALMENT Producer: VSI Units: 16 Version: 8.4 PAK Termination Date: 1-JAN-2019 Checksum: 2-FMEL-AJOM-IGBM-LCDL
4.4.2. License Registration and Product Installation
Follow the licensing and installation procedure provided with each product. You can save time if you consider the following variations and consequences for product installation and license registration:
If you register a license before you install a product, the product installation can be somewhat faster. You should register the license first, even though some products may allow installation first.
If you start to install a product and realize you need to register a license for it first, you can register the product from another session while the installation session waits at the ‘‘Is there a license PAK registered for this product?’’ After you register and load the license, you can use the product. Be sure to reply correctly to any licensing questions during the product installation. Check your product installation guide for specific restrictions.
To add a new node to an OpenVMS Cluster, you can register the new OpenVMS license before you add the node. You do not usually have to install the product again, unless the new node uses a new system disk.
If you are upgrading an OpenVMS Cluster environment, you may want to register all the OpenVMS licenses at one time after one node is operating. This eliminates some messages when the other nodes start up and keeps your nodes more available for interactive use.
The following figure illustrates the license registration and product installation route both for processors running the OpenVMS operating system and for layered products.
4.4.3. Registration Methods
Before you install a product?, register licenses in the License Database by entering PAK information in one of the following ways:
In response to prompts from SYS$UPDATE:VMSLICENSE.COM. This command procedure provides some default data and a menu-driven interface to help register the license.
With a LICENSE REGISTER command. The qualifier descriptions for the LICENSE REGISTER command describe the meaning of the PAK information. Each piece of PAK data correlates to a LICENSE REGISTER command qualifier.
Some products register their licenses during their own installation procedure. Unless you have a special circumstance, choose the registration method you prefer or the one recommended by your installation guide.
After a license is registered, it must be loaded to make it known on the current system (see Section 4.5).
4.4.4. Using VMSLICENSE.COM
The following steps show how to use the VMSLICENSE.COM procedure to register a license for a product called CRYPTICALMENT. The PAK information for this registration is taken from Example 4.1. Use the information from the PAK for your software product to register the license correctly.
Log in to the system manager’s account, SYSTEM.
Enter the following command and press Return:
$ @SYS$UPDATE:VMSLICENSE
The procedure displays the following menu:
VMS License Management Utility Options: 1. REGISTER a Product Authorization Key 2. AMEND an existing Product Authorization Key 3. CANCEL an existing Product Authorization Key 4. LIST the Product Authorization Keys 5. MODIFY an existing Product Authorization Key 6. DISABLE an existing Product Authorization Key 7. DELETE an existing Product Authorization Key 8. COPY an existing Product Authorization Key 9. MOVE an existing Product Authorization Key 10. ENABLE an existing Product Authorization Key 11. SHOW the licenses loaded on this node 12. SHOW the unit requirements for this node 99. EXIT this procedure Type '?' at any prompt for a description of the information requested. Press Ctrl/Z at any prompt to return to this menu. Enter one of the above choices [1]:
Enter 1. The procedure displays the following message:
* Do you have your Product Authorization Key? [YES]:
Enter Y. The procedure displays the following information and prompts for the issuer:
Use the REGISTER option to add a new license to a license database. A Product Authorization Key (PAK) provides the product name and information you need to register the license. You must enter all the information provided by your PAK exactly as it appears. Issuer [VSI]:- Press Return to specify VSI. The procedure prompts for the authorization number:
Authorization Number []:
Enter UAS12345 for the authorization number that appears on the PAK. The procedure prompts for the product name:
Product Name []:
Enter CRYPTICALMENT for the product name string that appears on the PAK. The procedure prompts for the producer:
Producer [VSI]:
Press Return to specify VSI as the producer. If the product you are registering is for OpenVMS I64, your PAK will list VSI as the producer. The procedure prompts for the number of units:
Number of Units []:
Enter 16 for the number of units. Note that you need to enter the number of units specified on your PAK. On OpenVMS I64 systems, the number of units will be much smaller than on OpenVMS Alpha systems as units are counted differently. The procedure prompts for the version:
Version []:
Enter 8.4 for the version number from the PAK. The procedure prompts for the key termination date:
Key Termination Date []:
Enter 1-JAN-2019 for the key termination date. The procedure prompts for the following information:
Availability Table Code []:
- Press Return after the Availability Table Code prompt. The procedure prompts for the following information:
Activity Table Code []:
Press Return after the Activity Table Code prompt. The procedure prompts for the following information:
Key Options []:
Enter the key options as listed on your PAK. The procedure prompts for the following information:
Product Token []:
Enter the product token as listed on your PAK. Press Return after the Product Token prompt. The procedure prompts for the following information:
Hardware-Id []:
- Enter the information as shown on your PAK. Press Return after the Hardware-Id prompt. The procedure prompts for the checksum:
Checksum []:
Enter 2-FMEL-AJOM-IGBM-LCDL for the checksum and press Return.
Note
The checksum string always begins with a number. The other 16 characters are always alphabetic characters from A through P.
The procedure displays the information you entered. For example:
Here is a list of the license information just entered: Issuer: VSI Authorization: UAS12345 Product Name: CRYPTICALMENT Producer: VSI Units: 16 Release Date: Version: 8.4 Termination Date: 1-JAN-2019 Availability: Activity: Options: Token: Hardware ID: Checksum: 2-FMEL-AJOM-IGBM-LCDL Is that correct? [YES]:Compare the information on the screen with the information on the PAK. If the information is correct, enter Y.
Note
If you enter PAK information incorrectly, you receive an error message, and the license is not registered. A checksum error can result when you enter incorrect information for the other items on the PAK. If you get an error, carefully check all the data that you entered.
If the information is incorrect, enter N. When the procedure displays the following question, enter Y:
Do you wish to make corrections? [YES]:
To make corrections, the procedure asks all of the questions again but supplies the data just entered as defaults for each data field.
If the procedure displays correct information, press Return.
If the procedure displays incorrect information, enter the new data.
If the procedure displays incorrect information that you wish to cancel without entering new data, enter the backslash ( \ ) character.
If you entered all the information correctly, the procedure displays the following message:
Registering CRYPTICALMENT license in SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB...
If you entered some information incorrectly but did not choose YES to make corrections, the procedure may display the following message:
Registering CRYPTICALMENT license in SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB... %LICENSE-F-BADCHK, checksum does not validate for CRYPTICALMENT Please review all entered PAK data, including the checksum. Do you wish to make corrections? [YES]:
To correct the data, enter Y.
If you enter an incorrect checksum string, the procedure responds as follows:
1-BGON-IAMA-GNOL-AIKO is not a valid license checksum string. Press RETURN for more information The license checksum is a 17-character verification string created by the PAK issuer for each PAK. The checksum string is presented in the format n-cccc-cccc-cccc-cccc, where n is an integer and c is a character from A through P. A PAK presents the checksum string with hyphen (-) characters for readability. Because the LMF does not count them for authorization, you can leave them out. Otherwise, you must enter the checksum string exactly as specified on your PAK. If a default value is displayed and you wish to use it just press the RETURN key. To cancel the use of default data without entering new data, enter the backslash (\) character. The license checksum is a required field for the REGISTER and AMEND options. Checksum []:Enter the correct checksum at the prompt.
- After the license is successfully registered, the procedure asks if you want to load the license on the current node, as follows:
Do you want to LOAD this license on this system? [YES]:
If you registered the PAK on a standalone system and you want to make the software available (active) immediately, enter Y. If you registered the license in an OpenVMS Cluster environment but do not want to make it available (active) on the current node, enter N. After you exit this procedure, you can enter the LICENSE LOAD command to load the license on the desired node.
If you enter Y and the license is successfully loaded, the procedure displays the following informational message and prompt:%LICENSE-I-LOADED, VSI CRYPTICALMENT was successfully loaded with 16 units VMS License Management Utility Options: 1. REGISTER a Product Authorization Key 2. AMEND an existing Product Authorization Key 3. CANCEL an existing Product Authorization Key 4. LIST the Product Authorization Keys 5. MODIFY an existing Product Authorization Key 6. DISABLE an existing Product Authorization Key 7. DELETE an existing Product Authorization Key 8. COPY an existing Product Authorization Key 9. MOVE an existing Product Authorization Key 10. ENABLE an existing Product Authorization Key 11. SHOW the licenses loaded on this node 12. SHOW the unit requirements for this node 99. EXIT this procedure Type '?' at any prompt for a description of the information requested. Press Ctrl/Z at any prompt to return to the main menu. Enter one of the above choices [1] To register another PAK, enter 1. Then respond to the questions, again entering information from a license PAK.
Enter 99 to exit the procedure.
You have registered your license(s). If the system displays an error message when the procedure attempts to load the license, this does not affect the license registration. If this occurs, refer to the sections of this manual that describe loading a license (see Section 4.5, the LICENSE LOAD, LICENSE UNLOAD, and LICENSE MODIFY command descriptions).
4.4.4.1. Using VMSLICENSE.COM in Batch Mode
You can use VMSLICENSE.COM in batch mode as well as interactively. Instead of entering the PAK data interactively from your terminal or workstation, you can create a VMSLICENSE data file with an editor and enter data obtained from your product PAKs (Example 4.2 shows sample PAK data). You can then invoke VMSLICENSE.COM, specifying the name of the new VMSLICENSE data file as a parameter on the same command line. The procedure displays the license data and performs the requested operation or operations using data only from the VMSLICENSE data file.
You can create a file that registers multiple licenses. VMSLICENSE.COM exits only when it reaches the end of the VMSLICENSE data file.
4.4.4.2. Invoking VMSLICENSE.COM with a VMSLICENSE Data File
To pass a VMSLICENSE data file to VMSLICENSE.COM, use the following format:
$ @VMSLICENSE [license-option] vmslicense-data-file [license-database]
When you invoke VMSLICENSE with a data file, you must specify REGISTER as the license-option. You cannot use data files with any of the other options that are available when using VMSLICENSE interactively.
You can specify a license-database on the command line or in the data file. Any License Database you specify in the data file overrides a License Database you specify on the command line.
For example, you can pass the data in the sample VMSLICENSE data file, shown in Example 4.2, with the following command line:
$ @VMSLICENSE REGISTER NODES_A_AND_B_VMS_LICENSE.DAT ! ! License for COBOL on NODEA ! DATABASE_FILE = SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB ISSUER = DEC PRODUCT_NAME = COBOL AUTHORIZATION = USA00326 UNITS = 1200 VERSION = 7.3 AVAILABILITY = A OPTIONS = MOD_UNITS,NO_SHARE CHECKSUM = 1-DELM-EAHF-ONIH-MBAH INCLUDE_NODE = NODEA ! <NEXT> ! ! License for COBOL on NODEB ! AUTHORIZATION = USA00327 UNITS = 800 CHECKSUM = 1-PATC-IDOH-EPOF-MOHG INCLUDE_NODE = NODEB
4.4.4.3. Creating VMSLICENSE Data Files
When you create a VMSLICENSE data file to be processed by VMSLICENSE.COM, you must follow these rules:
Specify all PAK data as parameters in the form of DCL assignment statements. Use the following format:
parameter = parameter-value ! comment
The following table lists the parameters allowed in the VMSLICENSE data file. You must use the exact parameter names, or VMSLICENSE ignores the line in the VMSLICENSE data file and returns an error message.
Separate the end of one license registration from the beginning of another with the following special license data separator:
<NEXT>
Precede each comment with an exclamation point; VMSLICENSE ignores everything to the right of an exclamation point when processing the line.
Separate words in the VMSLICENSE data file with any number of spaces or tabs.
List parameters in any order in the VMSLICENSE data file.
| Parameter | Description |
|---|---|
| AUTHORIZATION | String that, when used with the PAK issuer string, identifies the license you want to register. |
| AVAILABILITY | License unit code that corresponds to a LURT value or to a constant value. |
| CHECKSUM | Verification string of 17 characters created by the PAK
issuer for each PAK with this format:
n-cccc-cccc-cccc-cccc where:
n is an integer and c
is an alphabetic character from A through P. |
| DATABASE_FILE | Location of the License Database to be used. The default file specification is defined by the logical LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. |
| DATE | Product date specifying that the license authorizes use of all product versions released on or before the date. |
| HARDWARE_ID | Identification number of the hardware on which the product is licensed. On I64 systems, this field is used to specify the number of SOCKETS. If your PAK does not list SOCKETS=n in the HARDWARE_ID field, then your license is unlimited. |
| INCLUDE_NODE | Nodes in an OpenVMS Cluster environment that can access the licensed product. INCLUDE_NODE can specify one or more nodes in a clustered Galaxy. |
| ISSUER | Company that issued the PAK for this product. |
| OPTIONS | List of license options from a PAK. |
| PRODUCER | Company that owns this product. |
| PRODUCT_NAME | Product with a license to register. Use the product name exactly as it appears on the PAK. |
| RESERVE_LIST | Users (or activities) allowed to access the product license. |
| TERMINATION_DATE | Date on which the product license is no longer valid. |
| TOKEN | Product token string from a PAK |
| UNITS | Number of license units from a PAK. |
| VERSION | Version limits from a PAK of the product for which you have a license. |
4.4.4.4. Using VMSLICENSE.COM Default Value Rules
If you do not specify a value for a parameter in a VMSLICENSE data file, VMSLICENSE substitutes default values. The current default values are ISSUER=VSI and PRODUCER=VSI. All other license parameters have null values until you specify a value.
After you specify a license parameter in the VMSLICENSE data file, the parameter becomes the new default value until the next occurrence of the parameter sets a new default value. To set or reset the value of a parameter to null, use a line of the following form:
parameter = ""
For example, if the most recent PAK data set the INCLUDE_NODE parameter to a specific node, reset the parameter to null for the current and subsequent PAKs by entering the following:
INCLUDE_NODE = ""
4.4.5. Using the LICENSE REGISTER Command
You can directly register (and load) a license with LICENSE commands. For example:
$ LICENSE REGISTER CRYPTICALMENT /ISSUER=VSI - _$ /AUTHORIZATION=USA126087 /PRODUCER=VSI /UNITS=460 - _$ /VERSION=8.4 /TERMINATION_DATE=31-DEC-2019 /AVAILABILITY=E - _$ /OPTIONS=(MOD_UNITS) /CHECKSUM=1-BGON-IAMA-GNOL-AIKO $ LICENSE LOAD CRYPTICALMENT LICENSE-I-LOADED, VSI CRYPTICALMENT was successfully loaded with 460 units $
After you successfully register a license in the License Database (the default file specification is SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB), you can enter the LICENSE LIST/FULL command to display the data in the database.
$ LICENSE LIST /FULL /AUTHORIZATION=USA126087 CRYPTICALMENT Use CTRL/Z to exit, PF3-PF4 for Previous-Next Screen and Arrow Keys to scroll. License Management Facility V1.2 License Database File: SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB Created on: 28-AUG-2019 Created by user: GRAHAM Created by LMF Version: V1.2 ---------------------------------------------------------- Issuer: VSI Authorization: USA126087 Product Name: CRYPTICALMENT Producer: VSI Units: 460 Version: 8.4 Release Date: (none) PAK Termination Date: 31-DEC-2019 Availability: E (System Integrated Products) Activity: 0 Options: MOD_UNITS Hardware ID: Revision Level: 1 Status: Active Command: REGISTER Modified by user: GRAHAM Modified on: 23-SEP-2019 14:32:23.41
When a license is successfully loaded with VMSLICENSE.COM or the LICENSE LOAD command, LMF displays an informational message.
4.4.6. Displaying License Information
To display information from the License Database about specific licenses, enter the LICENSE LIST command.
To display information in memory about loaded licenses, enter the SHOW LICENSE command. This command displays licenses loaded on the current node, and displays any reservation list associated with each license.
4.5. Loading a License
To allow users to access a product, you must load each registered license. Loading a license transfers data from the on-disk License Database into system memory. The following table shows the methods of license loading for LMF:
| Method Used to Register a License | Loading Method |
|---|---|
| Registered with VMSLICENSE.COM | Confirm the load option. |
| Registered with the LICENSE REGISTER command | Use the LICENSE LOAD command. |
| Previously registered system starting up | System loads the license automatically. |
4.5.1. Loading Licenses in an OpenVMS Cluster Environment
Typically, any node can load a license registered in the common License Database. For predictability, security, performance, or economic reasons, you can limit which nodes can access a product license intended to be shared among nodes. In an OpenVMS Cluster environment, you control access by modifying the license’s include list. Use the LICENSE MODIFY command and either the /INCLUDE or /EXCLUDE qualifier to specify which cluster nodes can load the license. By changing the include list, you can create the effect of moving a product from node to node. Section 4.6.2 describes the process in detail. Note that you cannot share licenses that have the NO_SHARE option. They must be assigned to a single node.
You can also control which users in an OpenVMS Cluster environment can access a product license. Control access by modifying the license’s reservation list. Use the LICENSE MODIFY command with the /RESERVE qualifier to specify which users can access the license.
In an OpenVMS Cluster environment, license loading involves transferring, or loading, license information from the on-disk License Database into system memory of the current node. The number and combination of licenses for an OpenVMS Cluster environment can be complex, which in turn makes the loading process complex and sometimes confusing. The general rule is that nodes specified on include lists or not specified on exclude lists of the LICENSE MODIFY command can load a registered license.
As each system starts up, it loads any licenses to which it has access. If you need to load a license for all assigned nodes of a running cluster, you can use the OpenVMS System Management utility (SYSMAN), which is described in the VSI OpenVMS System Manager’s Manual. The following figure illustrates the loading process in an OpenVMS Cluster environment.
$ LICENSE MODIFY /EXCLUDE=THEATR product-name $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT /CLUSTER SYSMAN> LICENSE LOAD product-name
4.6. Managing Licenses After Registration
After you register licenses, you can manage them. While system managers can perform these tasks, managers of cluster environments and large multiple-user systems may also have an interest in managing products and product licenses.
For example, a cluster manager can use LMF to control which nodes can access a database product using important data (see Section 4.6.2). All system managers, however, may want to monitor license data using LICENSE commands. VMSLICENSE.COM, LICENSE commands, and the DCL command SHOW LICENSE can perform most license management tasks, including:
Listing registered licenses
Showing loaded licenses
Making loaded licenses unavailable—either permanently or temporarily
Transferring licenses from one database to another
Modifying licenses—such as termination dates or reservation lists
4.6.1. Restricting Product Use
LMF provides the following commands and qualifiers for controlling access to licensed products.
4.6.1.1. Fastest Method
The quickest method to restrict access to products registered in the License Database is to unload the license with a LICENSE UNLOAD command. The product becomes unavailable to new users and unavailable to all users when the last process using the product finishes. The product remains inaccessible until either you or the system reloads the license.
Although LICENSE UNLOAD is fast, it is not permanent. Typically, at system startup, LMF loads all the licenses registered in the License Database. In addition, a license that is loaded remains loaded until either the system is shut down or you intervene.
4.6.1.2. For Inactive Licenses
The following commands control license loading, which restricts product access. However, they do not unload loaded licenses or alter in-memory license data. For loaded licenses, use LICENSE UNLOAD.
LICENSE DISABLE
Prevents the specified license from being loaded until you enter a LICENSE ENABLE command.
LICENSE MODIFY /INCLUDE, LICENSE MODIFY /EXCLUDE
Makes the named nodes in an OpenVMS Cluster environment available or unavailable for license loading.
LICENSE MODIFY/UNITS=number
Limits access when you set the unit number to be less than that required by your processor or cluster. Use if your license has the MOD_UNITS option. Not all licenses have a specific number of units. Some licenses provide zero units, which is equivalent to unlimited units.
LICENSE MODIFY/RESERVE=user-name
Makes the product available only to the users named in the reservation list. You must use this method if your license has the RESERVE_UNITS option.
LICENSE COPY
Automatically disables a license as you reregister it in another License Database. This command is similar in effect to LICENSE DISABLE except that it also registers the license in the other database.
LICENSE ISSUE
Automatically disables a license so that you can then reregister it in another database. This command is similar in effect to LICENSE DISABLE except that it also produces a PAK replica to be registered elsewhere.
4.6.1.3. Permanent Methods
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.
4.6.2. Controlling Node Access to Licenses in Clusters
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.
4.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
4.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
Note
You can use the LICENSE MODIFY/UNITS command to increase the number of license units within the terms and conditions of your license agreement. If you need more license units than the number currently allowed by your license agreement, please contact your VSI representative for assistance in upgrading your license.
4.6.3. Controlling User Access
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, your reservation list with at least one, but no more than two, names. 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.
Note
LMF does not restrict you from creating incorrect reservation lists. If a user on a reservation list is being denied access to a product, check the reservation list (or reservation lists with multiple licenses for the same product) for the following:
Too many names. If you repeat a user name, LMF can reject a valid user name entry after reaching the allowed number of users for the license. LMF provides a warning when it loads a license with a list that is too long.
Incorrect spelling of user names. LMF simply compares and counts user names. If you misspell a name in the reservation list, LMF denies access to the user trying to access a product. LMF still counts each misspelled name as a potential user.
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 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.
4.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 control 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.
4.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 VSI 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
4.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 it 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 display 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 VSI C installed on all nodes in your OpenVMS Cluster, you can display VSI C license allocation on all the VAX nodes in the cluster from any VAX node with VSI C installed, but you will not observe any of the VSI C license allocations on the Alpha nodes.
Appendix A. Command Reference
LICENSE COPY
LICENSE COPY — Copies licenses from one License Database to another. When you use LICENSE COPY, LMF disables the source license and registers a copy in the destination License Database as if it were a new license. If the terms and conditions of your license contract allow it, you can reenable the source database license by using LICENSE ENABLE. LICENSE COPY cannot be used to create a copy of a license in the same database as the source of the copy.
Format
LICENSE COPY product-name[,...] output-database Parameters
- product-name[,...]
Name or names of products with a license to be copied to the output License Database.
- output-database
File specification of the License Database to which the license or licenses should be copied. This database must have been created previously using LICENSE CREATE. If you enter a partial file specification (for example, specifying only a directory), LMF$LICENSE is the default file name, and .LDB is the default file type. If you do not specify a device or directory, the current default device and directory are used.
Qualifiers
- /ALL
Positional qualifier. Specifies that all licenses with the given product name should be copied. This qualifier affects only the product name that immediately precedes it in the command string.
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to copy. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /DATABASE=filespec
Specifies the location of the License Database from which the license should be copied. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that issued the PAK for the product. Use this optional qualifier only if you need to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG, /NOLOG (default)
Controls whether LICENSE COPY displays the name of each license that it copies.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that owns the product for which you have a license. Use this optional qualifier only if you need to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
Description
The status of the source database license changes to disabled.
Network copies are supported within the limits of remote FAL access. If you use access control strings, such as "USERNAME password" within the file specification, the actual password string is not stored.
LICENSE COPY does not transfer any user-supplied data such as reservation lists, modified termination dates, modified units, include or exclude node lists, or comments.
Examples
$ LICENSE COPY FORTRAN BACKUP_DATA:BACKUP.LDB
This command copies the Fortran license in the default License Database to the BACKUP_DATA:BACKUP.LDB License Database. This command fails if there is more than one Fortran license in the default database.
$ LICENSE COPY FORTRAN /DATABASE=BACKUP_DATA:BACKUP.LDB - _$ BACKUP_DATA2:BACKUP2.LDB
This command copies the Fortran license in the source License Database to the BACKUP_DATA2:BACKUP2.LDB License Database. This command fails if there is more than one Fortran license in the source database.
$ LICENSE COPY FORTRAN /ALL BACKUP_DATA:BACKUP.LDB
This command copies all Fortran licenses in the default License Database to the BACKUP_DATA:BACKUP.LDB License Database.
$ LICENSE COPY FOR* BACKUP_DATA:BACKUP.LDB
This command copies all licenses whose product names begin with the string ‘‘FOR’’ from the default License Database to the BACKUP_ DATA:BACKUP.LDB License Database. In this case, using the wildcard character (*) implies the use of /ALL.
$ LICENSE COPY * BACKUP_DATA:BACKUP.LDB
This command copies all licenses from the default License Database to the BACKUP_DATA:BACKUP.LDB License Database. In this case, using the wildcard character (*) implies the use of /ALL.
$ LICENSE COPY * /PRODUCER=VSI BACKUP_DATA:BACKUP.LDB
This command copies all licenses with the producer name VSI from the default License Database to the BACKUP_DATA:BACKUP.LDB License Database. In this case, using the wildcard character (*) implies the use of /ALL.
$ LICENSE COPY D%% BACKUP_DATA:BACKUP.LDB
This command copies all licenses beginning with a "D" followed by exactly two characters from the default License Database to the BACKUP_ DATA:BACKUP.LDB License Database. In this case, using the wildcard character (%) implies the use of /ALL.
LICENSE CREATE
LICENSE CREATE — Creates a License Database with no license records. Because LMF provides a default License Database in SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB when OpenVMS is installed, you do not typically need to use this command. To use LMF, you must have a License Database file and the appropriate number of units for your system. On OpenVMS Alpha and VAX, the units are located in the License Unit Requirement Table (LURT) file (SYS$COMMON:[SYSEXE]LMF$LURT.DAT), which comes installed with OpenVMS. On OpenVMS I64, the units are based on the number of processor cores and the class of the machine specified in the PAK you receive with the license.
Format
LICENSE CREATE Parameters
None.
Qualifier
- /DATABASE=filespec
Specifies the location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system.
Example
$ LICENSE CREATE /DATABASE=SYS$MANAGER:LMF$LICENSE.LDB
This command creates the License Database named LMF$LICENSE.LDB in the directory SYS$MANAGER.
LICENSE DELETE
LICENSE DELETE — Deletes one or more licenses and all history information for those licenses from the License Database.
Format
LICENSE DELETE product-name[,...] Parameter
- product-name[,...]
Name or names of products with a license to be removed from the License Database. You can delete only licenses that have been registered.
Qualifiers
- /ALL
Positional qualifier. Specifies that all licenses with the given product name should be deleted. This qualifier affects only the product name that immediately precedes it in the command string.
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to delete. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /DATABASE=filespec
Specifies the location of the License Database from which the license or licenses should be deleted. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that issued the PAK for the product. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG, /NOLOG (default)
Controls whether LICENSE DELETE displays the name of each license that it deletes.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that owns the product for which you have a license. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /STATUS=[(keyword)[,...]]
Positional qualifier. Selects licenses to be deleted according to the product-name parameter specified and one or more license status keywords from the following list:
- ALL (default)—Deletes all specified licenses in the database.
- ACTIVE—Deletes all specified enabled licenses in the database. ACTIVE status means that the registered license is enabled for loading. For backward compatibility, the LICENSE LIST command identifies enabled licenses as having a status of active.
- DISABLED—Deletes all specified disabled licenses in the database.
- EXTINCT—Purges specified license information by deleting all extinct license records in the database. Extinct records are history records retained after a license is modified.
- CANCELED—Deletes all specified canceled licenses in the database. Note that current versions of LMF do not set license status to canceled. Old licenses may have this status. If you enter more than one keyword, separate them with commas, and enclose the list in parentheses. You can abbreviate each option to the minimum number of characters needed to uniquely identify it.
If you enter more than one keyword, separate them with commas, and enclose the list in parentheses. You can abbreviate each option to the minimum number of characters needed to uniquely identify it.
Description
Use LICENSE DELETE to delete licenses from the License Database. To tailor your command, use options to the /STATUS qualifier and wildcard characters in product name strings. File space is not released following LICENSE DELETE commands. For information on retrieving Record Management Services (RMS) file space, see the VSI OpenVMS Record Management Utilities Reference Manual.
Examples
$ LICENSE DELETE FORTRAN
This command deletes the Fortran license from the default License Database.
$ LICENSE DELETE FORTRAN, COBOL, PASCAL
This command deletes the Fortran, COBOL and Pascal licenses from the default License Database.
$ LICENSE DELETE FORTRAN /DATABASE=MY$DISK:MYDATA.LDB
This command deletes the Fortran license from the MY$DISK:MYDATA.LDB License Database.
$ LICENSE DELETE FORTRAN /ISSUER=XYLASOFT
This command deletes all licenses for the product named Fortran issued by XYLASOFT from the default License Database. If there are licenses for products named Fortran issued by companies other than XYLASOFT, they are not deleted.
$ LICENSE DELETE * /STATUS=(EXTINCT)
This command deletes all license records with a status of EXTINCT from the database. This is effectively a purge of all historical information.
LICENSE DISABLE
LICENSE DISABLE — Disables a license currently registered in the License Database.
Format
LICENSE DISABLE product-name[,...] Parameter
- product-name[,...]
Name or names of products with a license that you want to disable. You can disable only licenses that currently exist in the License Database. Enter the product name exactly as it appears on your Product Authorization Key (PAK).
Qualifiers
- /ALL
Positional qualifier. Specifies that all licenses with the given product name should be disabled. This qualifier affects only the product name that immediately precedes it in the command string.
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to disable. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /DATABASE=filespec
Specifies the location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that issued the PAK for the product. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG, /NOLOG (default)
Controls whether LICENSE DISABLE displays the name of each license that it disables.
Description
LICENSE DISABLE does not immediately affect loaded licenses. To affect a loaded license, you must first enter a LICENSE UNLOAD command, which unloads the license, but allows current processes to finish using the product. Note that to immediately disable all loaded licenses, you must shut down the system.
You cannot use LICENSE LOAD to activate a disabled license; you must first use LICENSE ENABLE.
LMF does not display error messages when either you or the system attempts to unload a disabled license.
Example
$ LICENSE DISABLE ABCD /PRODUCER=VSI
This command disables the license for ABCD software produced by VSI. Because no database is specified, LMF uses the default database.
LICENSE ENABLE
LICENSE ENABLE — Enables an existing license in the License Database so that you can load it with LICENSE LOAD. This command cancels the effect of LICENSE DISABLE, LICENSE COPY, and LICENSE ISSUE, which leave the license disabled. Newly registered licenses are enabled by default.
Format
LICENSE ENABLE product-name[,...] Parameter
- Parameter product-name[,...]
Name or names of products with a license to enable. You can enable only licenses that currently exist in the License Database. Enter the product name exactly as it appears on your PAK.
Qualifiers
- /ALL
Positional qualifier. Specifies that all licenses with the given product name should be enabled. This qualifier affects only the product name that immediately precedes it in the command string.
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to enable. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /DATABASE=filespec
Specifies the location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that issued the PAK for the product. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG, /NOLOG (default)
Controls whether LICENSE ENABLE displays the name of each license that it enables.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that owns the product for which you have a license. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
Description
Use LICENSE ENABLE to reestablish disabled licenses as available for loading with a LICENSE LOAD command.
Enabled licenses can combine with other licenses when loaded for use. Do not enable a license that has expired, and be sure that all include, exclude, and reservation lists are up to date.
Use LICENSE LIST to inspect each license before you enable it. Use LICENSE MODIFY to change include, exclude, and reservation lists.
Because errors do not occur until enabled licenses are loaded, consider entering LICENSE LOAD immediately to load each newly enabled license on each appropriate node in an OpenVMS Cluster. If another combinable license for the same product is already loaded, first unload it with LICENSE UNLOAD. Use the DCL command SHOW LICENSE to see which licenses are currently active on your system. After you unload the other license, enter LICENSE LOAD to load the combination of the newly enabled license and the previously active license.
Example
$ LICENSE ENABLE DECSET /PRODUCER=VSI
This command enables the license for DECset software. Because no database is specified, LMF uses the default database. Next, load the license with LICENSE LOAD.
LICENSE ISSUE
LICENSE ISSUE — Produces a replica of a Product Authorization Key (PAK) that is sent to a file or displayed on your terminal (the default). If the terms and conditions of your license contract allow it, you can then enter this PAK replica in the License Database of another processor. When you enter LICENSE ISSUE, LMF disables the license in the current License Database and marks the license DISABLED. To enable a license that has been marked ISSUED, enter LICENSE ENABLE. For License Databases connected to a network, consider using LICENSE MOVE.
Format
LICENSE ISSUE product-name[,...] Parameter
- product-name[,...]
Name or names of products with a license to be issued. You can issue only licenses that currently exist in the License Database. Enter the product name exactly as it appears on your PAK.
Qualifiers
- /ALL
Positional qualifier. Specifies that all licenses with the given product name should be issued. This qualifier affects only the product name that immediately precedes it in the command string.
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to issue. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /DATABASE=filespec
Specifies the location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that issued the PAK for the product. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG, /NOLOG (default)
Controls whether LICENSE ISSUE displays the name of each license that it issues.
- /OUTPUT[=filespec]
Specifies the name of the file to which your PAK replica is written. If you do not specify the /OUTPUT qualifier, or if you do not supply a file specification with this qualifier, the output is sent to SYS$OUTPUT. If you specify a file name that already exists, this command creates a new version of the file. If you specify a complete file name and version that already exists, this command appends the PAK replica to the existing file.
- /PROCEDURE, /NOPROCEDURE (default)
Specifies that the PAK replica is to be written in the form of a DCL command procedure. Use /PROCEDURE with the /OUTPUT qualifier to create a command procedure in a file. Then you can invoke the procedure to register the PAK replica in the License Database of another processor.
If you do not specify the /OUTPUT qualifier with /PROCEDURE, or if you do not supply a file specification with the /OUTPUT qualifier, the procedure is sent to SYS$OUTPUT.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that owns the product for which you have a license. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
Description
If your license contract allows it, use LICENSE ISSUE to move a license from a License Database on one processor (or OpenVMS Cluster environment) to a License Database on another processor. To move a license, enter LICENSE ISSUE, including enough PAK information to clearly identify the license. LICENSE ISSUE automatically disables the current license but does not immediately unload it; LMF does not terminate any active processes. To unload the license, enter a LICENSE UNLOAD command.
After you issue the PAK replica, read the information, and register it on the new processor as you would any PAK, or, if you used the /PROCEDURE qualifier with the /OUTPUT qualifier, invoke the new DCL command procedure to register the license.
Note that the PAK replica includes only PAK information registered with a LICENSE REGISTER command. The replica does not include any changes made with other LICENSE commands.
Example
$ LICENSE ISSUE /OUTPUT=SYS$MANAGER:FORTRAN.PAK - _$ /PRODUCER=DEC FORTRAN
This command issues a PAK replica, which you can use to register the Fortran license on a new processor (or OpenVMS Cluster environment), and puts it into the file named FORTRAN.PAK. The next step is to print the file, read the information, and, using a LICENSE REGISTER command or VMSLICENSE.COM, enter the correct information in the License Database of the new processor. The Fortran license in the current License Database is marked ISSUED and is disabled.
$ LICENSE ISSUE /PRODUCER=DEC VOLSHAD
This command displays, at the current terminal, a PAK replica with the information from the VOLSHAD (Volume Shadowing) license. This display is reproduced below. The license registered in the current License Database is marked ISSUED and is disabled. You can register the data from this replica of a PAK in the License Database of another processor using either VMSLICENSE.COM or LICENSE REGISTER.
Software Product Authorization Key Replica Issued by CASPER Issued on 24-FEB-2001 14:23 ----------------------------------- Issuer: DEC Authorization: ALS-WM-93166-5573 Product Name: VOLSHAD Producer: DEC Units: 460 Version: 5.4 PAK Termination Date: 31-DEC-2001 Availability: E Options: MOD_UNITS Checksum: 1-ADEB-DOCJ-NENC-KDBM
$ LICENSE ISSUE /PROCEDURE /OUTPUT=FORTRAN-USA10.COM - _$FORTRAN /AUTHORIZATION=USA-10
This command generates a DCL command procedure such as the following to be used for registering the specified license in a License Database:
$! Software Product Authorization Key Replica $! Issued by CASPER $! Issued on 23-Oct-2001 14:23 $ LICENSE REGISTER FORTRAN - /ISSUER=DEC - /PRODUCER=DEC - /AUTHORIZATION=USA-10 - /UNITS=400 - /VERSION=5.4 - /AVAILABILITY=F - /CHECKSUM=1-HIDN-INDA-COMP-DAHH
LICENSE LIST
LICENSE LIST — Displays information from the License Database on disk about the specified license or licenses. Use one or more qualifiers to control the form, content, and location of information displayed. The SHOW LICENSE command, described in the VSI OpenVMS DCL Dictionary and in this appendix, displays information from the License Database in memory.
Format
LICENSE LIST [product-name[,...]] Parameter
- product-name[,...]
Name or names of products with a license that you want to list. You can list only licenses that currently exist on disk in the License Database. You can specify one product name or use wildcard characters to display licenses. The product-name parameter is optional; the default is to display all of the licenses.
Qualifiers
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to list. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /BEFORE
Used with /TERMINATION_DATE and /RELEASE_DATE, selects only those licenses whose times are before the time specified with the other qualifiers. The /BEFORE qualifier cannot be used with the /SINCE qualifier.
- /BRIEF (default)
Specifies a listing from the License Database that includes only the license product and producer names.
- /DATABASE=filespec
Specifies the location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /FULL
Specifies a listing from the License Database that includes a full display of the specified license or licenses.
- /HISTORY
Specifies a listing from the License Database that includes the history records in the License Database for the specified license or licenses.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that issued the PAK for the product. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /OUTPUT[=filespec]
Specifies the name of the file to which your list is written. If you do not specify the /OUTPUT qualifier, or if you do not supply a file specification with this qualifier, the output is sent to SYS$OUTPUT.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company (for example, VSI) that owns the product for which you have a license. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /RELEASE_DATE=date
Used with /BEFORE or /SINCE, specifies a listing from the License Database that includes only licenses with a release date on or after the date specified. The date must be presented in the standard OpenVMS format: dd-mmm-yyyy. The default value is /SINCE /RELEASE_DATE=TODAY.
- /SELECTION_WEIGHT
Produces a full display that includes the current selection weights assigned to individual PAKs. /SINCE Used with /TERMINATION_DATE and /RELEASE_DATE, selects only those licenses whose times are after the time specified with the other qualifiers. /SINCE cannot be used with /BEFORE.
- /TERMINATION_DATE[=date]
Used with /BEFORE or /SINCE, specifies a listing from the License Database that includes only licenses with a termination date on or after the date specified. The date must be presented in the standard OpenVMS format: dd-mmm-yyyy. The default value is /SINCE /TERMINATION_DATE=TODAY.
- /VERSION=nn.nn
Positional qualifier. Specifies the version number of the product for which you have a license. Versions use the format integer.integer. You can specify wildcard syntax as *.* but not * alone. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
Description
LICENSE LIST displays license records as they appear on disk in the License Database. LICENSE LIST /BRIEF does not produce a display with history records. You can control the displays as follows:
After you enter LICENSE LIST with the /BRIEF qualifier, you can scroll through the display with the arrow keys on your keyboard.
After you enter LICENSE LIST with the /FULL or /HISTORY qualifier, which displays the first LICENSE record, you can see the other records one at a time by pressing Return. You can also scroll through the license records using the Previous Screen key (or PF3) and the Next Screen key (or PF4).
For any LICENSE LIST display, use the arrow keys to scroll vertically or horizontally one line at a time. Press Ctrl/Z to exit from the display.
Note that a LICENSE LIST command may display the status of a registered license as Active. This means the registered license is enabled for loading; it has not been disabled. It does not necessarily mean the license was loaded with a LICENSE LOAD command. The LICENSE LIST command displays only information on disk in the License Database; enter SHOW LICENSE to determine all active licenses on the current system.
You can also list licenses using the VMSLICENSE.COM command procedure.
LICENSE LOAD
LICENSE LOAD — Loads licenses, making them available for product authorization on the current node. The product licenses must be registered and current in the License Database. That is, they must not have been disabled or issued. If the license is already loaded, LMF returns an informational message, unloads the license, and then loads the license. To use this command, you need CMKRNL, SYSNAM, and SYSPRV privileges.
Format
LICENSE LOAD [product-name][,...] Parameter
- [product-name][,...]
Name or names of products with a license to be loaded. You can load only licenses that are currently registered and enabled in the License Database. Enter the product name exactly as it appears on your Product Authorization Key (PAK). If you do not specify a product name, LICENSE LOAD loads all of the products that are registered and enabled. You cannot use wildcard characters for product-name.
Qualifiers
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to register. You must enter the authorization string exactly as it appears on your PAK. This qualifier affects only the product name that immediately precedes it in the command string.
- /DATABASE=filespec
Location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /ISSUER=string
Positional qualifier. Name of the company (for example, DEC) that issued the PAK for the product. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG (default), /NOLOG
Controls whether or not LICENSE LOAD displays a message to acknowledge the loading of each license.
- /OEDB - I64 only
Using this qualifier refreshes the contents of the OE database. The contents of the OE database are described in a datafile (LMF$OE.DAT). If new variants of operating environments become available, VSI will provide a new datafile with information on the new or changed operating environments. Using LICENSE LOAD/OEDB updates your OE database without having to reboot the system.
- /PRODUCER=string
Positional qualifier. Name of the company that owns the product for which you have a license. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /UNLOAD (default), /NOUNLOAD
When requested to load a license that is currently loaded, LMF first automatically unloads it and then loads the latest license. You can specify /NOUNLOAD to verify whether or not there is already a license loaded; LMF issues the warning LICENSE-W-ALREADYLOADED and does not load the license. To then load the license, follow these steps:
Manually unload the current license with the LICENSE UNLOAD command.
Reissue the LICENSE LOAD command.
Description
The LICENSE LOAD command loads licenses registered in the License Database. To use a licensed product, ensure that the system loads the registered license. When you register a license with VMSLICENSE.COM, you can confirm an option to load the license, whereas if you register a license with LICENSE REGISTER, you must also load it with LICENSE LOAD.
Use LICENSE LOAD only after you register a new license; LMF automatically loads all registered licenses at each subsequent system startup. You can enter LICENSE LOAD at other times to load modifications made with other LICENSE commands.
You can enter one LICENSE LOAD command without product-name to load all the available registered licenses.
Note
Registered licenses are enabled for loading by default. You can, however, disable a registered license to prevent loading.
A LICENSE START command entered interactively or when the system reboots also loads all licenses that are registered and enabled.
If you register multiple licenses for a single product, LICENSE LOAD loads all of the matching licenses. You do not typically load individual licenses, and you cannot unload individual licenses for a product. The Availability, Activity, Personal Use, and User license units of the multiple licenses work in concert to provide more product availability.
In an OpenVMS Cluster environment, each system loads licenses when it reboots. If you need to load a license for all assigned nodes of a running cluster, you can do one of the following:
Log in to each OpenVMS Cluster node, and enter LICENSE LOAD.
Invoke the OpenVMS SYSMAN utility to execute the LICENSE LOAD command on the desired OpenVMS Cluster nodes. See the VSI OpenVMS System Manager's Manual for details on defining your management environment and executing commands on a list of nodes.
A LICENSE LOAD command can fail, sending a message to the operator communication manager (OPCOM) for any of the following reasons:
Insufficient license units are registered for the current node.
The current date is later than the license termination date.
A license checksum does not match the rest of the license data. Check for data corruption in the License Database.
If you attempt to load a disabled license or a license modified to exclude the current node in an OpenVMS Cluster environment, OPCOM does not display an error message.
If licenses for more than one product are being loaded, LICENSE LOAD continues with the next license following a failure.
Example
$ LICENSE MODIFY /INCLUDE=MUSIC FORTRAN $ LICENSE LOAD FORTRAN
The commands in this example illustrate a situation in which you enter a LICENSE LOAD command interactively. LICENSE LOAD loads the product Fortran on the node MUSIC. Data in the License Database determines whether the license is successfully loaded on the specified node.
$ LICENSE LOAD BASIC %LICENSE-W-NOLOAD, license was not loaded for BASIC -LICENSE-F-EXCEEDED, attempted usage exceeds active license limits
This command attempts to load the product BASIC, but LICENSE LOAD fails because too few license units are registered to authorize use on the current processor.
LICENSE MODIFY
LICENSE MODIFY — Modifies a license for system management and license-sharing purposes. Immediately changes data in the License Database, but your modifications do not affect the running system until you load the modified license.
Format
LICENSE MODIFY qualifier[,...] product-name[,...] Parameter
- product-name[,...]
Name or names of products with a license to be modified. You can modify only licenses that currently exist in the License Database.
Qualifiers
- /ADD
Used with the /INCLUDE or /EXCLUDE qualifier, specifies that the node names provided are to be added to the previously established include or exclude lists. Used with the /RESERVE qualifier, specifies that the user names provided are to be added to the previously established reservation lists. When you use /ADD, you do not need to retype the entire list to add a new node name or user name.
- /ALL
Positional qualifier. Modifies all the licenses with the given product name. This qualifier affects only the product name that immediately precedes it in the command string.
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to modify. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /COMBINE, /NOCOMBINE
Modifies a PAK by adding or removing the COMBINE option. If the PAKs are combinable, LMF combines them during license loading.
- /COMMENT=string
Specifies a string of text. Use this comment field of up to 63 characters to associate information for this transaction with the license. History records for the license retain this license information. If you specify more than one word, enclose the text in quotation marks (""). This qualifier is optional. The text in the comment field is replaced only when you enter new comments with another LICENSE MODIFY command. At this point the old comment text is available as a history record.
- /DATABASE=filespec
Specifies the location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /EXCLUDE=(node-name[,node-name,...])
Specifies that the named node or nodes in an OpenVMS Cluster environment cannot access the licensed product. The excluded nodes cannot load (with a LICENSE LOAD or LICENSE START command) the license registered in the License Database. Each node-name argument must be a System Communications Services (SCS) node name or a system parameter set with the System Generation utility (SYSGEN). The node name might not be the same as the DECnet node name. If you specify more than one node name, separate them with commas, and enclose the list in parentheses. This qualifier is optional. To modify previously defined lists without having to retype all of the node names, use the /ADD or /REMOVE qualifiers with /EXCLUDE. You can control license access to nodes with /EXCLUDE and control user access with /RESERVE, but you cannot use these qualifiers on the same command line. To use both types of control with the same license, you must enter separate LICENSE MODIFY commands.
- /INCLUDE=(node-name[,node-name,...])
Specifies that the named node or nodes in an OpenVMS Cluster environment can access the licensed product. Only the included nodes can load (with a LICENSE LOAD or LICENSE START command) the license registered in the License Database. Each node-name argument must be an SCS node name, or a system parameter set with SYSGEN. The node name might not be the same as the DECnet node name. Licenses for the OpenVMS operating system usually specify the NO_SHARE option on their PAKs. In a cluster environment you must restrict each of these OpenVMS licenses to a single node. If you did not do this when registering with VMSLICENSE.COM, enter LICENSE MODIFY/INCLUDE=node-name, specifying one SCS node name for each OpenVMS license. To specify more than one SCS node name for a license that does not specify NO_ SHARE, separate the names with commas, and enclose the list in parentheses. This qualifier is optional. To modify previously defined lists without having to retype all of the node names, use the /ADD or /REMOVE qualifiers with /INCLUDE. You can control license access to nodes with /INCLUDE and control user access with /RESERVE, but you cannot use these qualifiers on the same command line. To use both types of control with the same license, you must enter separate LICENSE MODIFY commands.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, DEC) that issued the PAK for the product. Use this qualifier only if it is required to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG, /NOLOG (default)
Controls whether LICENSE MODIFY displays the name of each license that it modifies.
- /NO_SHARE, /NONO_SHARE
Specifies whether to add or subsequently remove /NO_SHARE from a PAK. Adding /NO_SHARE prevents the sharing of the PAK units with other cluster nodes. PAKs with /NO_SHARE require you to provide the SCS node name of the cluster node that will be using this particular license. See the /INCLUDE qualifier for more information. Note that if /NO_SHARE is present on your PAK when you register it, you cannot remove the option using /NONO_SHARE. Only if you add /NO_SHARE with the MODIFY command, can you subsequently remove it.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company (for example, DEC) that owns the product for which you have a license. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /REMOVE
Used with the /INCLUDE or /EXCLUDE qualifier, specifies that the node names provided are to be removed from the previously established include or exclude lists. Used with the /RESERVE qualifier, specifies that the user names provided are to be removed from the previously established reservation lists. When you use /REMOVE, you do not need to retype the entire list to remove a node name or user name.
- /RESERVE=(user-name[,user-name,...])
Specifies that the license or licenses are to be reserved for use by the users listed in the user-name parameter. Users not listed are denied access to the product. The value applied to user-name differs from product to product. See your Software Product Description (SPD) for details. Most products define user-name to be the user name OpenVMS maintains for each account. This is the name you type at the Username prompt during login. If your PAK specifies the RESERVE_UNITS option, you must assign one or more users to a reservation list. On OpenVMS Alpha and VAX systems, the number of user names allowed per list depends on the number of activity units available and a constant value or the License Unit Requirement Tables (LURTs). Calculate this number as you would for any Activity License. For example, a 200-unit license with a constant value of 100 is a two-user license. On OpenVMS I64 systems, units are expressed in single units that directly correlate to the constant value listed. You can also create and modify a reservation list for Availability and regular Activity Licenses that do not specify the RESERVE_UNITS option. Because these licenses do not limit the number of names on the list, you can assign as many names as you like to the reservation list. All users not on the list are denied access. Although you can control license access to nodes with /INCLUDE and /EXCLUDE qualifiers and control user access with the /RESERVE qualifier, you cannot use these qualifiers on the same command line. If you want to use both types of control with the same license, you must enter separate LICENSE MODIFY commands. Use the /ADD and /REMOVE qualifiers for further control in modifying previously established reservation lists.
- /SELECTION_WEIGHT=number
Modifies the selection weight. Selection-weight values determine the order in which LMF checks multiple licenses when a product makes a license grant request. LMF checks higher-weighted licenses before lower-weighted ones. Specify arbitrary numbers between 1 and 1000.
Note
You cannot modify selection weights for Availability Licenses.
To restore the selection weight of a PAK to the default value, enter the LICENSE MODIFY command with /SELECTION_WEIGHT=0. For example, you can use either of the following commands:
$ LICENSE MODIFY FORTRAN /SELECTION_WEIGHT=0 $ LICENSE MODIFY FORTRAN /NOSELECTION_WEIGHT
- /TERMINATION_DATE=date
Date at which the product license is to be terminated. If your PAK supplied a license termination date, LMF uses the earliest date to determine the termination date. The date must be presented in the standard OpenVMS format: dd-mmmyyyy. If you want to restrict a product from further use today, enter yesterday’s date; LMF terminates the license at the end of the day specified.
- /UNITS=n
Number of license units you want on a license that includes the MOD_UNITS option. If your PAK allows you to modify the license units, use this qualifier to change the value in the License Database.
Description
Use the LICENSE MODIFY command to modify a license. To control which nodes in a cluster environment have access to what software, use LICENSE MODIFY with the /INCLUDE or /EXCLUDE qualifier. For example, you can load licenses for products used less often or requiring limited access on one node.
If you do not specify which nodes can load a license (with a LICENSE LOAD or LICENSE START command), LMF loads a license on a first-come, first-served basis. When your license has insufficient license units for full cluster environment use, control product access with an include list.
Because most OpenVMS PAKs use the /NO_SHARE option, in a cluster environment you must restrict these operating system licenses to one node. Enter LICENSE MODIFY/INCLUDE=node-name, specifying only one SCS node name for each OpenVMS license.
To control which users have access to a product, use LICENSE MODIFY with the /RESERVE qualifier. You can create and modify a reservation list for any kind of license. Only users on the reservation lists are allowed access to the product. 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 and a constant value or the License Unit Requirement Tables (LURTs). Calculate this number as you would for any Activity License. For example, a 200-unit license with a constant value of 100 is a two-user license. Use the /ADD and /REMOVE qualifiers in conjunction with the /INCLUDE, /EXCLUDE, and /RESERVE qualifiers when you modify existing include, exclude, and reservation lists. To add comments about a license in the License Database, use LICENSE MODIFY with the /COMMENT qualifier. If your PAK includes the MOD_UNITS option, you can use the /UNITS qualifier to specify the number of license units you want for your registered license. Use the other LICENSE MODIFY command qualifiers only as needed to identify the correct license. You can also modify a license record using the VMSLICENSE.COM command procedure.
List Size Restrictions
On any single PAK, the sum of characters contained in all lists must not exceed 5000 characters. Because the length of names varies and some overhead is used for each name, this 5000-character limit cannot be expressed as an exact number of permissible names. However, VSI guarantees that at least 400 names, in total, can be specified in the various types of lists. For example, each of the following represents the minimally guaranteed number of names:
- Reservation list with up to 400 user names
- Reservation list with up to 400 user names Reservation list with up to 200 user names plus an include list with up to 200 node names (totaling up to 400) Reservation list with up to 200 user names plus an exclude list with up to 200 node names (totaling up to 400)
- Reservation list with up to 200 user names plus an include list with up to 200 node names (totaling up to 400)
- Include list with up to 400 node names
- Exclude list with up to 400 node names
Note
If you enter more names than are permitted, LICENSE LIST might not be able to display all names entered. In this case, you receive the error message LICENSE-F-CORRUP. However, the License Database is not actually corrupt, and the PAKs can still be loaded into memory (though the names are not displayed).
The LICENSE LOAD and LICENSE START commands can load into memory a reservation list with no more than 30,000 characters. (Include and exclude lists, which are not loaded into memory, are irrelevant to the 30,000-character limit.)
Because the length of names varies and some overhead is used for each name, this 30,000-character limit cannot be expressed as an exact number of permissible names. But VSI guarantees that, for each product, at least 2000 user names can appear on reservation lists. In the case of an OpenVMS Cluster, this is a per-node limit.
Note that because 2000 user names is a per-product limit and because there can be more than one PAK per product, the number of user names on a per-product basis is the sum of the user names specified on each PAK.
For example, if three activity PAKs for the DECwrite product were registered on a system and each PAK specified a reservation list with 200 user names, the total number of user names for that product is 600. This is safely below the 30,000-character (2000 user name) limit and below the 5000-character (400 user name) limit.
Examples
$ LICENSE MODIFY /EXCLUDE=(DANCE,THEATR) - _$ /COMMENT="Modified to exclude nodes DANCE & THEATR 10/23/04" - _$ FORTRAN
This command modifies the Fortran license in the License Database so that users cannot access Fortran from the nodes named DANCE and THEATR. A comment is added to the database record for future reference.
$ LICENSE MODIFY /ADD /INCLUDE=(DRAMA) - _$ /COMMENT="Modified to add node named DRAMA 10/23/04" - _$ FORTRAN
This command modifies the Fortran license in the License Database so that users can access Fortran from the node DRAMA in addition to any nodes previously named in the license include list.
$ LICENSE MODIFY /UNITS=1200 FORTRAN $ LICENSE LOAD FORTRAN
This command changes the license units on a license with the MOD_UNITS option.
$ LICENSE MODIFY /EXCLUDE="" FORTRAN
This command removes all nodes from the previously established exclude list. All nodes now have access to the Fortran license.
LICENSE MOVE
LICENSE MOVE — Moves one or more licenses from one License Database to another. When you use LICENSE MOVE, LMF deletes those licenses from the source License Database. For License Databases not connected to a network, consider using the LICENSE ISSUE /PROCEDURE command.
Format
LICENSE MOVE product-name[,...] output-database Parameter
- product-name[,...]
Name or names of products with a license to be moved to the output License Database.
- output-database
File specification of the License Database to which the license or licenses should be moved. This database must have been previously created using LICENSE CREATE. If you enter a partial file specification (for example, specifying only a directory), LMF$LICENSE is the default file name, and .LDB is the default file type.
If you do not specify a device or directory, the current default device and directory are used.
Qualifiers
- /ALL
Positional qualifier. Specifies that all licenses with the given product name should be moved. This qualifier affects only the product name that immediately precedes it in the command string.
- /AUTHORIZATION=string
Positional qualifier. Specifies a string that helps identify the license you want to modify. You must enter the authorization string exactly as it appears on your PAK. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /DATABASE=filespec
Specifies the location of the License Database from which the license or licenses should be moved. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB on an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default License Database name and location.
- /ISSUER=string
Positional qualifier. Specifies the name of the company (for example, DEC) that issued the PAK for the product. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
- /LOG, /NOLOG (default)
Controls whether LICENSE MOVE displays the name of each license that it moves.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company (for example, DEC) that owns the product for which you have a license. Use this optional qualifier only if you need it to identify the license. This qualifier affects only the product name that immediately precedes it in the command string.
Description
If your license contract allows it, use LICENSE MOVE to move a license from one License Database to another. To move a license, enter LICENSE MOVE, including enough PAK information to clearly identify the license. LICENSE MOVE automatically deletes the license from the source License Database.
Note that the moved license includes only the general PAK information normally provided by LICENSE REGISTER. LICENSE MOVE does not transfer any user-supplied data such as reservation lists, modified termination dates, modified units, include or exclude node lists, or comments.
Examples
$ LICENSE MOVE FORTRAN ALT_SYS2:LMF$LICENSE.LDB
This command moves the Fortran license in the default License Database to the ALT_SYS2:LMF$LICENSE.LDB output License Database. This command fails if the default database contains more than one Fortran license.
$ LICENSE MOVE FORTRAN /DATABASE=LMFDATA:LMF$LICENSE.LDB - _$ ALT_SYS:LMF$LICENSE.LDB
This command moves the Fortran license in the source License Database, LMFDATA:LMF$LICENSE.LDB, to the destination License Database, ALT_SYS:LMF$LICENSE.LDB. This command fails if the source License Database contains more than one Fortran license.
$ LICENSE MOVE FORTRAN /ALL ALT_SYS2:LMF$LICENSE.LDB
This command moves all Fortran licenses in the default License Database to the output License Database, ALT_SYS2:LMF$LICENSE.LDB.
$ LICENSE MOVE * ALT_SYS2:LMF$LICENSE.LDB
This command merges two databases by moving all licenses in the default License Database to the output License Database, ALT_SYS2:LMF$LICENSE.LDB.
LICENSE REGISTER
LICENSE REGISTER — Adds a new license to the License Database. A Product Authorization Key (PAK) provides the product name and information you need to register the license. You must enter all information provided by your PAK exactly as it appears. You can also register a new product license with the command procedure SYS$UPDATE:VMSLICENSE.COM, which provides a prompt-based interface to the LICENSE REGISTER command.
Format
LICENSE REGISTER product-name Parameter
- product-name
Name of the product with a license to register. You can register only licenses that do not currently exist in the License Database. You can register multiple licenses for the same product when they have different authorization numbers. Enter the product name exactly as it appears on your PAK.
You cannot use wildcard characters for the product-name parameter with this command.
Qualifiers
- /ACTIVITY=code | CONSTANT=integer
Specifies a license unit code that corresponds to a License Unit Requirement Table (LURT) or to a constant value. If your PAK supplies an activity code, you must enter the code exactly as it appears. The current codes are A, B, C, D, E, F, G, H, and I. If your PAK specifies the keyword CONSTANT, then you must also specify the integer value. This denotes a constant requirement for all System Marketing Models (SMMs) equal to the value given. If your PAK specifies the decimal value 0, then the license has no requirement for that license type. PAK issuers determine the value for this element.
- /AUTHORIZATION=string
Specifies a string that helps identify the license you want to register. You must enter the authorization string exactly as it appears on your PAK.
- /AVAILABILITY= code | CONSTANT=integer
Specifies a license unit code that corresponds to a License Unit Requirement Table (LURT) or to a constant value. If your PAK supplies an availability code, you must enter the code exactly as it appears. The current codes are A, B, C, D, E, F, G, H, and I. If your PAK specifies the keyword CONSTANT, then you must also specify the integer value from your PAK. PAK issuers determine the value for this element.
- /CHECKSUM=string
Specifies a 17-character verification string created by the PAK issuer for each PAK. The checksum string is presented in the format n-cccc-cccc-cccc-cccc, where n is an integer and c is an alphabetic character from A through P. A PAK presents the checksum string with hyphen ( - ) characters for readability. Because LMF does not count hyphens for authorization, you do not have to enter them. Otherwise, you must enter the checksum string exactly as it appears on your PAK.
- /DATABASE=filespec
Specifies the location of the License Database. The default file specification is defined by the logical name LMF$LICENSE, which points to SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB in an unmodified OpenVMS system. Use this optional qualifier only if you do not use the default database.
- /HARDWARE_ID=string
Specifies the identification number of the hardware on which the product is licensed. If your PAK supplies a hardware identification number, you must enter the information exactly as it appears. On I64 systems, the HARDWARE_ID string is in the format SOCKETS=n.
- /ISSUER=string
Specifies the name of the company (for example, DEC) that issued the PAK for the product. Note that the PAK issuer is often the same as the producer. You must enter the information exactly as it appears on your PAK.
- /OPTIONS=[(keyword[,...])]
Specifies LICENSE REGISTER options. If your PAK supplies any license options, you must enter this information exactly as it appears. Table A–1 describes the available keywords.
Table A.1. LICENSE REGISTER /OPTIONS Keywords Keyword Meaning ALPHA Identifies Availability Licenses for Alpha systems. HARD_COMPLIANCE Identifies a license that will enforce compliance to license terms. IA64 Identifies Licenses for I64 systems. IA64_ALPHA Identifies Activity Licenses that are valid for OpenVMS I64 and OpenVMS Alpha systems. IA64_ALPHA_VAX Identifies Activity Licenses that are valid for OpenVMS I64, OpenVMS Alpha, and OpenVMS VAX systems. MOD_UNITS You can modify the number of license units. NO_SHARE You cannot use the license on more than one processor in an OpenVMS Cluster environment. To use this license in a cluster, designate it for one node. Issue LICENSE MODIFY with the / INCLUDE qualifier. PCL Designates a Per Core License on an OpenVMS I64 system. RESERVE_UNITS The license must be assigned to one or more users. Reserve the license using LICENSE MODIFY with the /RESERVE qualifier. USER Designates a User License. VAX_ALPHA Identifies Availability Licenses that are valid for both OpenVMS VAX and OpenVMS Alpha systems. VIRTUAL License can only be used on a VM guest. If you enter more than one keyword, separate them with commas, and enclose the list in parentheses. You can abbreviate each option to the minimum number of characters needed to uniquely identify it.
- /PRODUCER=string
Specifies the name of the company (for example, VSI) that owns the product for which you have a license. You must enter the information exactly as it appears on your PAK.
- /RELEASE_DATE=date
Specifies a product release date such that the license authorizes use of all product versions released on or before the date. If your PAK supplies a product release date, you must enter the information exactly as it appears. The date must be presented in the standard OpenVMS format: dd-mmm-yyyy.
- /TERMINATION_DATE=date
Specifies the date on which the product license terminates. If your PAK supplies a license termination date, you must enter it exactly as it appears. The date must be presented in the standard OpenVMS format: dd-mmm-yyyy.
- /TOKEN=string
Specifies a string of information associated with some products. This option can enable or disable certain product features. See your product documentation for details. If your PAK provides token information, you must enter it exactly as it appears.
- /UNITS=number
Specifies the number of license units for your license. You must enter the number exactly as it appears on your PAK even if your PAK specifies the MOD_UNITS option.
Description
LICENSE REGISTER is the primary LICENSE command. Before you enter a LICENSE REGISTER command, you need a PAK that supplies the information required to enter a license in the License Database.
You can register additional licenses for products that already exist in the License Database. If you register another combinable license in the License Database, LMF combines the license units during a LICENSE LOAD or LICENSE START command. This allows more product availability or activity for the same product. The checksum number supplied with your PAK is calculated from the other information supplied with the PAK. Thus, you must enter each qualifier necessary to supply information from your particular PAK. If you enter LICENSE REGISTER without a required qualifier, LMF returns a checksum error.
Example
$ LICENSE REGISTER FORTRAN /ISSUER=DEC /AUTHORIZATION=USA-10 - _$ /PRODUCER=DEC /UNITS=400 /VERSION=5.4 - _$ /AVAILABILITY=F /CHECKSUM=1-HIDN-INDA-COMP-DAHH
This command adds the license for the product Fortran to the default License Database. Fortran becomes licensed using the availability formula with 400 license units available.
$ LICENSE REGISTER DVNETRTG /ISSUER=DEC /AUTHORIZATION=USA-15 - _$ /PRODUCER=DEC /UNITS=1000 /VERSION=4.0 - _$ /AVAILABILITY=E/CHECKSUM=1-COOD-AGON-EFIC-HING
This command adds the license for the product DVNETRTG (DECnet for OpenVMS Routing) to the default License Database. In the example, DVNETRTG is licensed using the availability formula with 1000 license units.
LICENSE START
LICENSE START — This command loads all licenses that are registered and enabled in the License Database into memory. On OpenVMS Alpha and VAX systems, it sets up the License Unit Requirement Table (LURT) for your system. On OpenVMS I64 systems, it loads the operating environment table and all per core licenses into memory. Because the OpenVMS operating system issues a LICENSE START command during system startup, you should need this command only if system startup fails. To use this command, you need CMKRNL, SYSNAM, and SYSPRV privileges on OpenVMS Alpha systems. In addition to those three, you also need SYSLCK privilege on OpenVMS I64 systems. To load the licenses in the License Database of a system with LMF already started, use LICENSE LOAD.
Format
LICENSE START Parameter
None.
Example
$ LICENSE START
On OpenVMS Alpha and VAX systems, this command sets up the LURT for your system and loads all the licenses that are registered and enabled in the License Database. On OpenVMS I64 systems, this command loads the operating environment table and all PCL licenses into memory.
LICENSE UNLOAD
LICENSE UNLOAD — Unloads a license, making the product unavailable from the current node. The product license or licenses must be registered in the License Database and must have been previously loaded with an interactive or automatic LICENSE LOAD command. Running processes are allowed to continue to completion. To use this command, you need CMKRNL, SYSNAM, and SYSPRV privileges.
Format
LICENSE UNLOAD product-name[,...] Parameter
- product-name[,...]
Name of the product to be unloaded. You can unload only licenses that have been loaded. Enter each product name exactly as it appears on its Product Authorization Key (PAK). You cannot use wildcard characters for product-name.
Qualifiers
- /LOG, /NOLOG (default)
Controls whether LICENSE UNLOAD lists the name of each unloaded license.
- /PRODUCER=string
Positional qualifier. Specifies the name of the company that owns the product for which you have a license. The default string for this qualifier is VSI. If VSI is not the producer of the product, you must use this qualifier to identify the product. This qualifier affects only the product name that immediately precedes it in the command string. Wildcard characters are not allowed.
Description
LICENSE UNLOAD affects all units for a single product even if the loaded units are combined from multiple licenses. In such a case, you cannot unload the units from a single license. You must unload all the units.
You are not required to unload a loaded license before modifying data in the License Database. To maximize product availability, modify licenses in the License Database first, and then load the changes by entering a LICENSE UNLOAD command followed by a LICENSE LOAD command.
Example
$ LICENSE UNLOAD /PRODUCER=DEC FORTRAN
This command unloads the DEC Fortran license on the node from which it is entered.
$ LICENSE UNLOAD PASCAL,FORTRAN
This command unloads the VSI Pascal and VSI Fortran licenses on the node from which it is entered.
SHOW LICENSE
SHOW LICENSE — Displays software product licenses active on the current node and lists the names attached to a license (known as the RESERVE list). The SHOW LICENSE command displays the License Database information currently in your system’s memory. Use the License Management utility command, LICENSE LIST, when you want to view the License Database information that is on disk.
Format
SHOW LICENSE [product-name [,...]] Parameter
- product-name
Specifies the name or names of activated software product licenses to display. The asterisk (*) and the percent sign (%) wildcard characters are allowed. If you do not specify a product name, information is displayed about all active product name licenses. The product-name parameter is incompatible with the /UNIT_REQUIREMENTS qualifier.
Qualifiers
- /ALL - I64 only
Use with /HIERARCHY to display all OE licenses defined in the LMF database.
- /BEFORE
Use with /TERMINATION_DATE and /RELEASE_DATE qualifiers. Selects only those licenses whose times are before the time specified with the other qualifiers. The /BEFORE qualifier cannot be used with the /SINCE qualifier.
- /BRIEF (default)
Displays a summary of information about the specified active product licenses. Use the /FULL qualifier to obtain a complete product license listing.
- /CHARGE_TABLE
Synonym for the /UNIT_REQUIREMENTS qualifier.
- /CLUSTER
Use with the /UNIT_REQUIREMENTS qualifier to display the license unit requirements for every node in an OpenVMS Cluster.
- /EXACT
Use with the /PAGE=SAVE and /SEARCH qualifiers to specify a search string that must match the search string exactly and must be enclosed with quotation marks ( ‘‘ ’’ ). If you specify the /EXACT qualifier without the /SEARCH qualifier, exact search mode is enabled when you set the search string with the Find (E1) key.
- /FULL
Displays a summary of information about the specified active product licenses, including Product Authorization Key (PAK) options and the reserve list (if any). On I64 systems, lists the licenses for OEs currently active on the system.
- /HIERARCHY - I64 only
Displays the hierarchy of licenses for operating environments active on the current node.
- /HIGHLIGHT[=keyword]
Use with the /PAGE=SAVE and /SEARCH qualifiers to specify the type of highlighting you want when a search string is found. When a string is found, the entire line is highlighted. You can use the following keywords: BOLD, BLINK, REVERSE, and UNDERLINE. BOLD is the default highlighting.
- /OE[=OE name] - I64 only
When an OE name is specified, displays the contents the of named operating environment. Currently, valid OE names are BOE and HAOE. When no OE name is specified, displays the operating environment currently active on the node.
- /OUTPUT[=filespec], /NOOUTPUT
Controls where the output of the SHOW LICENSE command is sent. By default, the output of the SHOW LICENSE command is sent to the current SYS$OUTPUT device (usually your terminal). To send the output to a file, use the /OUTPUT qualifier followed by a file specification. The asterisk (*) and the percent sign (%) wildcard characters are not allowed in the file specification. If you enter a partial file specification (for example, specifying only a directory), SHOW is the default file name and .LIS is the default file type. If you enter the /NOOUTPUT qualifier, output is suppressed.
- /PAGE[=keyword], /NOPAGE (default)
Controls the display of license information on the screen. You can use the following keywords with the /PAGE qualifier:
CLEAR_SCREEN - Clears the screen before each page is displayed.
SCROLL Displays information one line at a time.
SAVE[=n] Enables screen navigation of information, where n is the number of pages to store.
The /PAGE=SAVE qualifier allows you to navigate through screens of information. The /PAGE=SAVE qualifier stores up to 5 screens of up to 255 columns of information. When you use the /PAGE=SAVE qualifier, you can use the following keys to navigate through the information:
Key Sequence Description Up arrow key, Ctrl/B Scroll up one line. Down arrow key Scroll down one line. Left arrow key Scroll left one column. Right arrow key Scroll right one column. Find (E1) Specify a string to find when the information is displayed. Insert Here (E2) Scroll right one half screen. Remove (E3) Scroll left one half screen. Select (E4) Toggle 80/132 column mode. Prev Screen (E5) Get the previous page of information. Next Screen (E6), Return, Enter, Space Get the next page of information. F10, Ctrl/Z Exit Exit. (Some utilities define these differently.) Help (F15) Display utility help text. Do (F16) Toggle the display to oldest/newest page. Ctrl/W Refresh the display. The /PAGE qualifier is not compatible with the /OUTPUT qualifier.
- /PRODUCER=producer-name
Displays software product licenses active on the current node and supplied by the specified producer. The asterisk (*) and the percent sign (%) wildcard characters are allowed for the producer-name parameter. You cannot use the /PRODUCER qualifier with the /UNIT_REQUIREMENTS qualifier.
- /RELEASE_DATE=[date_time]
Allows listing licenses using release dates as selection criteria.
- /SEARCH="string"
Use with the /PAGE=SAVE qualifier to specify a string that you want to find in the information being displayed. Quotation marks are required for the /SEARCH qualifier, if you include spaces in the text string. You can also dynamically change the search string by pressing the Find key (E1) while the information is being displayed. Quotation marks are not required for a dynamic search.
- /SINCE(default)
Use with the /TERMINATION_DATE and /RELEASE_DATE qualifiers. Selects only those licenses whose times are on or after the time specified with the other qualifiers. The /SINCE qualifier cannot be used with the /BEFORE qualifier.
- /TERMINATION_DATE=date_time
Allows listing licenses using termination dates as selection criteria.
- /UNIT_REQUIREMENTS
On I64 systems, displays information about the type of system, the number of processor cores active, and the number of sockets. The /UNIT_REQUIREMENTS qualifier is incompatible with the product-name parameter and with the /BRIEF and /PRODUCER qualifiers.
- /USAGE
Tells you how many license units are loaded, how many are currently allocated, and how many are currently available, as well as the license type for each product on the system. Use with the /FULL qualifier to display complete information—including the PID, process name, node, or user name—for each instance of use of the product. You need group privilege to see the list of users in your group who have allocated license units; you need world privilege to see the list of users in all groups.
In an OpenVMS Cluster, if you own multiple license types for a single product, you are limited to viewing the usage information for the license type loaded on the node from which you are executing the SHOW LICENSE /USAGE command. To find out the usage of the other license type loaded on another node, issue the command on that node. You can also use the System Management (SYSMAN) utility to do this.
In an OpenVMS Cluster, usage information is limited to the local license type. For example, VAX and Alpha availability licenses are considered by LMF to be 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 DEC C installed on all nodes in your OpenVMS Cluster, you can display DEC C license allocation on all the VAX nodes in the cluster from any VAX node with DEC C installed, but you cannot display the DEC C license allocation on the Alpha nodes.
Usage information is not available for unlimited licenses (a license with 0 units). Clusterwide usage information is not available for personal use or NO_SHARE licenses. Refer to the VSI OpenVMS License Management Utility Manual for more information on license types.
- /WARNING_INTERVAL=n, /NOWARNING_INTERVAL
Displays a warning stating the number of licenses that will terminate in n days. The default is 30 days.
- /WRAP, /NOWRAP (default)
Use with the /PAGE=SAVE qualifier to limit the number of columns to the width of the screen and to wrap lines that extend beyond the width of the screen to the next line.
The /NOWRAP qualifier extends lines beyond the width of the screen and can be seen when you use the scrolling (left and right) features provided by the /PAGE=SAVE qualifier.
Description
The DCL command SHOW LICENSE displays software product licenses active on the current node. An active license is one that has been registered in the LICENSE database and has been loaded into system memory. To register and activate software product licenses, use the License Management utility (LICENSE) or VMSLICENSE.COM. Some licenses are registered automatically during product installation.
To display licenses registered in the LICENSE database, use the LICENSE LIST command.
Example
$ SHOW LICENSE/FULL Active licenses on node WTPOOH: DVNETEND Producer: DEC Units: 0 Version: 0.0 Date: (none) Termination Date: (none) Availability: E (System Integrated Products) Activity: 0 MOD_UNITS VAX-VMS Producer: DEC Units: 0 Version: 0.0 Date: (none) Termination Date: (none) Availability: A (VMS Capacity) Activity: 0 MOD_UNITS NO_SHAREIn this example, the SHOW LICENSE command displays all the active licenses on the current node, WTPOOH.
$ SHOW LICENSE/OE/FULL Current Operating Environment on node GAFFER at 27-APR-2015 20:27:31.95: --------- Operating Environment ---------- ------ Units ------ Name Description Type Level Loaded Total HAOE High Availability H 5 0 0 GWLM RTR-SVR VMSCLUSTER VMSCLUSTER-CLIENT AVAIL-MAN RMSJNL VOLSHAD DECRAM OMS OPENVMS-I64 OPENVMS-USER DVNETEND DW-MOTIF UCX TDC X500-ADMIN-FACILITY X500-DIRECTORY-SERVER CIFS
The SHOW LICENSE command in this example shows the licenses in the current operating environment HAOE.
$ SHOW LICENSE/BRIEF Active licenses on node WTPOOH: --- Product ID ---- ---- Rating ----- -- Version -- Product Producer Units Avail Activ Version Release Termination DVNETEND DEC 0 E 0 0.0 (none) (none) VAX-VMS DEC 0 A 0 0.0 (none) (none)
The SHOW LICENSE command in this example displays a summary of all the active licenses on the current node WTPOOH.
$ SHOW LICENSE/UNIT_REQUIREMENTS OpenVMS I64/LMF Charge Information for node GAFFER This is an VSI Integrity BL860c i4 (2.13GHz/24.0MB), with 8 cores active This platform supports up to 2 processor socket(s) Type: PPL, Units Required: 8 (I64 Per Processor) Type: PCL, Units Required: 8 (I64 Per Core)
The SHOW LICENSE command in this example displays information in the License Unit Requirement Table (LURT).
SHOW LICENSE/WARNING_INTERVAL=8000 test0% Active licenses on node PICCHU: --- Product ID ---- ---- Rating ----- -- Version -- Product Producer Units Avail Activ Version Release Termination TEST01 DEC 0 A 0 0.0 (none) (none) TEST02 DEC 0 B 0 0.0 10-JAN-2014 12-NOV-2014 TEST03 DEC 0 C 0 0.0 30-DEC-2014 (none) TEST04 DEC 0 D 0 0.0 (none) 25-AUG-2015 TEST05 DEC 0 E 0 0.0 14-NOV-2016 14-AUG-2016 %SHOW-I-TERMIMM, 3 licenses will terminate in 8000 days
The /WARNING_INTERVAL qualifier in this example displays three licenses that will terminate in 8000 days.
$ SHOW LICENSE/USAGE/FULL TEST_CAP View of loaded licenses from node: SLTG24 30-DEC-2014 15:45:59 Availability license DEC TEST_CAP usage information: Units Node 10 SLTG24 10 SLTG43 600 TORN8O 600 LTNUP Units loaded: 620 Units allocated: 1220 Units available: ***
In this example, the number of units allocated appears to be greater than the total units loaded and the units available value is three asterisks (***). When you see three asterisks (***) as the number of units available, it is generally not a cause for alarm. This situation might arise when the License Database (LDB) has been updated on disk, but the new information has not been propagated to the License Database in memory on all nodes in the cluster. This node, SLTG24, happens to be one of the nodes that has not received the latest LDB information. To update the information in the License Database in memory for the TEST_CAP product, enter the following commands:
$ LICENSE UNLOAD TEST_CAP $ LICENSE LOAD TEST_CAP
The next time you issue the SHOW LICENSE /USAGE command the three asterisks (***) in display should disappear. If, however, you are using multiple LDB files in a cluster, you should read Section 1.3.
$ SHOW LICENSE/UNIT_REQUIREMENT/CLUSTER VMS/LMF Cluster License Unit Requirements Information 24-DEC-2011 14:05:51.65 Node A B C D E F G H I KARBO - - - 100 50 10 - - 10 JENJON - - - 100 50 10 - - 10 HELENA 143 - - - 600 2400 - - 2400 SHAKTI - - - 100 50 10 - - 10 Total Cluster Unit Requirements Type: A, Units Required: 143 (VMS Capacity) Type: B, * Not Permitted * (VMS Server) Type: C, * Not Permitted * (VMS Concurrent User) Type: D, Units Required: 300 (VMS Workstation) Type: E, Units Required: 750 (System Integrated Products) Type: F, Units Required: 2430 (Layered Products) Type: G, * Not Permitted * (VMS Reserved) Type: H, * Not Permitted * (Alpha Layered Products) Type: I, Units Required: 2430 (Layered Products)
In this example, the display shows how many license units are required for each license type (A, B, etc.) on each node in the cluster. If a row of three asterisks (***) is displayed for a node, it means that the node is in the process of booting.
$ SHOW LICENSE/OE=BOE --------- Operating Environment ---------- ------ Units ------ Name Description Type Level Loaded Total BOE Base H 2 - 0 Gaffer-i-XE16-B4N
This example shows the BOE license on node GAFFER.
$ SHOW LICENSE/OE=BOE/FULL --------- Operating Environment ---------- ------ Units ------ Name Description Type Level Loaded Total BOE Base H 2 - 0 DECRAM OMS OPENVMS-I64 OPENVMS-USER DVNETEND DW-MOTIF UCX TDC X500-ADMIN-FACILITY X500-DIRECTORY-SERVER CIFS
This example shows all the licenses in the BOE operating environment on node GAFFER.
$ SHOW LICENSE/HIER/FULL Operating Environment Hierarchy ------------------------------- --------- Operating Environment ---------- ------ Units ------ Name Description Type Level Loaded Total HAOE High Availability H 5 0 0 GWLM MCOE Mission Critical H 4 - 0 RTR-SVR VMSCLUSTER VMSCLUSTER-CLIENT EOE Enterprise H 3 - 0 AVAIL-MAN RMSJNL VOLSHAD BOE Base H 2 - 0 DECRAM OMS FOE Foundation H 1 - 0 OPENVMS-I64 OPENVMS-USER DVNETEND DW-MOTIF UCX TDC X500-ADMIN-FACILITY X500-DIRECTORY-SERVER CIFS$ SHOW LICENSE OPENVMS-I64-HAOE Active licenses on node GAFFER: ------- Product ID -------- ---- Rating ----- -- Version -- Product Producer Units PCL Activ Version Release Termination OPENVMS-I64-HAOE VSI 8 1 0 0.0 (none) 1-APR-2014
This example shows the details of the HAOE license on node GAFFER.
Appendix B. Difference Between LICENSE LIST and SHOW LICENSE
This example shows the differences between the LICENSE LIST command, which displays license information stored on disk, and the SHOW LICENSE command, which displays license information stored in memory. The first command registers a Fortran license, as follows:
$ LICENSE REGISTER FORTRAN /ISSUER=DEC /AUTHORIZATION=USA-10 - _$ /PRODUCER=DEC /UNITS=400 /VERSION=6.0 - _$ /AVAILABILITY=F /CHECKSUM=1-HIDN-INDA-COMP-DAHH
This command adds the license for the product Compaq Fortran to the default License Database. To see the information registered in the database, enter a LICENSE LIST command, as follows:
$ LICENSE LIST /FULL FORTRAN
Use Ctrl/Z to exit, PF3-PF4 for Previous-Next Screen and Arrow keys to
scroll.
License Management Facility V1.2
License Database File: SYS$COMMON:[SYSEXE]LMF$LICENSE.LDB
Created on: 17-AUG-2000
Created by user: GRAHAM
Created by LMF Version: V1.2
-----------------------------------------------------
Issuer: DEC
Authorization: USA-10
Product Name: FORTRAN
Producer: DEC
Units: 400
Version: 6.0
Release Date: (none)
PAK Termination Date: (none)
Availability: F (Layered Products)
Activity: 0
Options:
Hardware ID:
Revision Level: 1
Status: Active
Command: REGISTER
Modified by user: LESH
Modified on: 21-AUG-2000 14:32:23.41Notice that for status the LICENSE LIST command displays Active. This means the registered license is enabled for loading, that it has not been disabled or canceled. It does not necessarily mean the Fortran license was loaded with a LICENSE LOAD command. Because the LICENSE LIST command sees only the License Database on disk, you must enter a SHOW LICENSE command to refer to the License Database in memory to determine whether a license is active on the current system. For example:
$ SHOW LICENSE/FULL
Active licenses on node BIODTL:
CRYPTICALMENT
Producer: DEC
Units: 400
Version: 7.3
Release Date: (none)
Termination Date: 31-DEC-2001
Availability: E (System Integrated Products)
Activity: 0
MOD_UNITS
VAX-VMS
Producer: DEC
Units: 400
Version: 6.0
Release Date: (none)
Termination Date: (none)
Availability: A (VMS Capacity)
Activity: 0
MOD_UNITS
NO_SHAREThe SHOW LICENSE command in this example displays all the active licensed products on the current node named BIODTL; the Fortran license has not yet been loaded. After you load the Fortran LICENSE, the SHOW LICENSE command displays the license. For example:
$ LICENSE LOAD FORTRAN
LICENSE-I-LOADED, DEC FORTRAN was successfully loaded with 400 units
$ SHOW LICENSE /FULL
Active licenses on node BIODTL:
CRYPTICALMENT
Producer: DEC
Units: 400
Version: 7.3
Release Date: (none)
Termination Date: 31-DEC-2001
Availability: E (System Integrated Products)
Activity: 0
MOD_UNITS
FORTRAN
Producer: DEC
Units: 400
Version: 6.0
Release Date: (none)
Termination Date: (none)
Availability: F (Layered Products)
Activity: 0
VAX-VMS
Producer: DEC
Units: 400
Version: 6.0
Release Date: (none)
Termination Date: (none)
Availability: A (VMS Capacity)
Activity: 0
MOD_UNITS
NO_SHAREWith the OpenVMS operating system, you start the installation first. Although VSI does not recommend it, you can install some software products first and license them later. See your software product’s documentation for details.