HP OpenVMS Systems Documentation

HP OpenVMS License Management Utility Manual

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

If two or more licenses are combinable except for the above attributes, you can force LMF to combine them with the following command:

LICENSE MODIFY product-name /COMBINE

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 reservartion 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

With the forced combination of multiple licenses, LMF sets the termination date, release date, and version number of the combined license to the earliest dates and version numbers that apply to the individual licenses being combined. The following table shows the combined license that results from the forced combination of two licenses:

This chapter describes licensing on OpenVMS I64 systems, which differs from licensing on Alpha and VAX in several ways. Key differences are described in the following sections:

• Operating environments and tiering
• New license type--per core licenses (PCL), which replaces per procssor licenses (PPL)
• Compliance checking and reporting

On OpenVMS I64 systems, operating system licenses are bundled with additional products into operating environments, called OEs. These environments offer base operating system functionality along with additional capability, based on the OE. The operating environments are tiered in a hierarchy. Each higher-level OE contains everything in the lower tiers plus additional functionality. Currently, three tiers of operating environments are offered:

• Foundation Operating Environment (FOE)
  This OE includes the base operating system plus networking transport, internet capability, and other basic functions.
• Enterprise Operating Environment (EOE)
  The EOE contains everything in the FOE plus additional system management capability and volume shadowing.
• Mission Critical Operating Environment (MCOE)
  The MCOE contains everything in the EOE plus clustering and other advanced capabilities.

These operating environments have new licenses associated with them as follows:

• OPENVMS-I64-FOE
• OPENVMS-I64-EOE
• OPENVMS-I64-MCOE

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 MCOE) are available individually. For example, you can add a cluster license to the foundation 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 HP. When that occurs, HP 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 SPD (SPD 82.34.xx) 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/HIER/FULL


                     Operating Environment Hierarchy
                     -------------------------------

--------- Operating Environment ---------- ------ Units ------
Name     Description            Type Level   Loaded      Total
MCOE     Mission Critical         H    3          2          2
  RTR-SVR
  VMSCLUSTER
  VMSCLUSTER-CLIENT
EOE      Enterprise               H    2          -          2
  DECRAM
  RMSJNL
  AVAIL_MAN
  VOLSHAD
  SYSMGT
FOE      Foundation               H    1          2          4
  OPENVMS-I64
  OPENVMS-USER
  DVNETEND
  DW-MOTIF
  UCX
  TDC
  DCOM-MIDL
  X500-ADMIN-FACILITY
  X500-DIRECTORY-SERVER

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 EOE, use the following command:

$ SHOW LICENSE/OE=EOE/FULL

$ show license/oe=eoe/full
--------- Operating Environment ---------- ------ Units ------
Name     Description            Type Level   Loaded      Total
EOE      Enterprise               H    2          2          2
  DECRAM
  RMSJNL
  AVAIL_MAN
  VOLSHAD
  SYSMGT
  OPENVMS-I64
  OPENVMS-USER
  DVNETEND
  DW-MOTIF
  UCX
  TDC
  DCOM-MIDL
  X500-ADMIN-FACILITY
  X500-DIRECTORY-SERVER

This example shows all products within the EOE without distinguishing between operating environment hierarchies. All products contained in FOE and EOE 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

On OpenVMS I64 systems, there are two license types:

• Per core licenses - for OpenVMS I64 systems, replaces per processor licenses (PPL)
• Activity licenses

The following sections describe these licenses.

3.2.1 Per Core Licenses

An Integrity-specific license type, per core license (PCL), implements the licensing model on OpenVMS I64 systems. The PCL model licenses a product based on the number of active processor cores on the system, not the static rating scheme as on Alpha and VAX systems. 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.2. Any changes to the system are noted and checked for compliance.

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: HP
           AUTHORIZATION NUMBER: USA126087
                   PRODUCT NAME: C
                       PRODUCER: HP
                NUMBER OF UNITS: 3
                        VERSION:
           PRODUCT RELEASE DATE:
           KEY TERMINATION DATE: 31-DEC-2004
        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

On OpenVMS I64 systems, LMF checks for two types of compliance:

• Hardware compliance - checks license against hardware system rating
• Soft compliance - checks number of PCL licenses against the number of active processor cores

The following sections describe each.

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 HP 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 excluse list to your licenses bu 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 HP Integrity rx4640 server (4 sockets), two HP Integrity rx2620 servers (2 sockets), and one HP 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 Section 4.6 or 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, HP provides a reporting mechanism that flags noncompliance for per core licenses. For example, if you load a license with only 2 units 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 for foundation operation environment on this system might look like the following:

                         ISSUER: HP
           AUTHORIZATION NUMBER: USA126087
                   PRODUCT NAME: OPENVMS-I64-FOE
                       PRODUCER: HP
                NUMBER OF UNITS: 1
                        VERSION:
           PRODUCT RELEASE DATE:
           KEY TERMINATION DATE: 31-DEC-2004
        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 to 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 Foundation Operating Environment (FOE) 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 foundation operating environment on this system might look like the following:

                         ISSUER: HP
           AUTHORIZATION NUMBER: USA126087
                   PRODUCT NAME: OPENVMS-I64-FOE
                       PRODUCER: HP
                NUMBER OF UNITS: 2
                        VERSION:
           PRODUCT RELEASE DATE:
           KEY TERMINATION DATE: 31-DEC-2004
        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 foundation 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.