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

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

	License 1	License 2	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

This chapter describes licensing on OpenVMS Integrity server 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 processor licenses (PPL)
• Compliance checking and reporting

On OpenVMS Integrity server 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.

With OpenVMS Version 8.4, the three-tier Operating Environment model that consisted of Foundation Operating Environment (FOE), Enterprise Operating Environment (EOE) and Mission Critical Operating Environment (MCOE) is replaced with a two- tier Operating Environment model consisting of Base Operating Environment (BOE) and High Availability Operating Environment (HA-OE).

Base Operating Environment (BOE)

This OE includes the base operating system plus networking transport, internet capability, and other basic functions. BOE license includes all components of FOE and two components from EOE. The following products that were formerly part of the EOE are now part of BOE:

• DECram for OpenVMS
• HP OpenVMS Management Station

High Availability Operating Environment (HA-OE)

The HA-OE contains everything in BOE and additional system management capability, volume shadowing, clustering, and other advanced capabilities. HA-OE license includes four components of EOE, all components of MCOE, and Global Work Load Manager (gWLM). The following products that were formerly part of the EOE are now part of HA-OE:

• HP Availability Manager
• OpenView Performance Agent (OVPA) for OpenVMS
• RMS Journaling for OpenVMS
• HP Volume Shadowing for OpenVMS

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

• OPENVMS-I64-BOE
• OPENVMS-I64-HAOE

The FOE licenses automatically upgrade to BOE and EOE or MCOE licenses automatically upgrade to HA-OE, upon upgrading to OpenVMS Version 8.4.

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 HA-OE) 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 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 HAOE High Availability H 5 2 2 GWLM MCOE Mission Critical H 4 - 2 RTR-SVR VMSCLUSTER VMSCLUSTER-CLIENT EOE Enterprise H 3 - 2 AVAIL-MAN RMSJNL VOLSHAD BOE Base H 2 - 2 DECRAM OMS FOE Foundation H 1 - 2 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 HA-OE, use the following command:

$ SHOW LICENSE/OE=HAOE/FULL --------- Operating Environment ---------- ------ Units ------ Name Description Type Level Loaded Total HAOE High Availability H 5 4 4 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 HA-OE without distinguishing between operating environment hierarchies. All products contained in HA-OE and BOE 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 Integrity server systems, there are two license types:

• Per core licenses - for OpenVMS Integrity server 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 Integrity server 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 Integrity server 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

• 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 Integrity server 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 Integrity server 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 5.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 Integrity server 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 Integrity server 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 base operation environment on this system might look like the following:

ISSUER: HP AUTHORIZATION NUMBER: USA126087 PRODUCT NAME: OPENVMS-I64-BOE PRODUCER: HP NUMBER OF UNITS: 1 VERSION: PRODUCT RELEASE DATE: KEY TERMINATION DATE: 31-DEC-2012 AVAILABILITY TABLE CODE: ACTIVITY TABLE CODE: KEY OPTIONS: PRODUCT TOKEN: HARDWARE I.D.: SOCKETS=2 CHECKSUM: 2-NFCA-BAPO-FEJF-BDLL

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 Base Operating Environment (BOE) by this 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 license with 1 unit.

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: HP AUTHORIZATION NUMBER: USA126088 PRODUCT NAME: OPENVMS-I64-BOE PRODUCER: HP NUMBER OF UNITS: 2 VERSION: PRODUCT RELEASE DATE: KEY TERMINATION DATE: 31-DEC-2012 AVAILABILITY TABLE CODE: ACTIVITY TABLE CODE: KEY OPTIONS: PRODUCT TOKEN: HARDWARE I.D.: SOCKETS=4 CHECKSUM: 2-FODI-MDHC-PAIF-CEEG

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.