|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
 |
 |
HP OpenVMS systems documentation |
|
| Previous | Contents | Index |
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:
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:
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:
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 I64 systems, which differs from licensing on Alpha and VAX in several ways. Key differences are described in the following sections:
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:
These operating environments have new licenses associated with them as follows:
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 2 2 2 RTR-SVR VMSCLUSTER VMSCLUSTER-CLIENT EOE Enterprise H 1 - 2 DECRAM RMSJNL AVAIL_MAN VOLSHAD SYSMGT FOE Foundation H 0 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 1 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 CPUs 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:
The following sections describe these licenses.3.2.1 Per Processor Licenses
A new license type, per processor license (PPL), implements a new licensing model on OpenVMS I64 systems. The PPL model licenses a product based on the number of active CPUs on the system, not the static rating scheme as on Alpha and VAX systems. Each active CPU requires one PPL unit. If you increase or decrease the number of active CPUs on a system, the requirement for PPL licenses changes.
A PPL license is required to run operating environments, OE products purchased separately (like clustering), and many standalone products on OpenVMS I64 systems.
PPL 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 CPUs, you purchase additional PPL licenses.
LMF constantly checks the number of PPL licenses against the number of active CPUs and enforces a soft compliance model described in Section 3.3.2. Any changes to the system are noted and checked for compliance.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: 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:
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 CPUs. Your PAK for an I64 system may have an entry in the HARDWARE_ID field (expressed as CPU_SOCKETS=n). For example, if your PAK has the entry CPU_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 CPU sockets on a system by using the following command:
$ SHOW LICENSE/CHARGE_TABLE OpenVMS I64/LMF Charge Information for node MACCHU This is an HP rx2600 (900MHz/1.5MB), with 2 CPUs active, 2 socket(s) Type: PPL, Units Required: 2 (I64 Per Processor) |
This example shows that node MACCHU has 2 CPU sockets.
You can buy a license for an unlimited number of sockets. In that case, there is no keyword specified in the HARDWARE_ID field.3.3.2 Soft Compliance
In addition to having a license appropriate for your system hardware rating, you must also have a per processor license (PPL) for each active CPU. The PPL units for I64 systems are in units of 1 per CPU.
To assist you in maintaining the terms and conditions of your licensing agreement, HP provides a reporting mechanism that flags noncompliance for per processor licenses. For example, if you load a license with only 2 units a system with 4 active CPUs, 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 CPUs.
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 PPL 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 PPL units for each active CPU.3.3.3 Sample License Checks
The following examples show how LMF combines checking the hardware rating and the PPL licensing requirements for OpenVMS I64 systems.
An rx2600 is a 2-socket system and each socket can accept only a single-CPU processor 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.: CPU_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 CPU_SOCKETS=2 keyword to the HARDWARE_ID field. This license could be loaded on any system with 1 or 2 sockets. The number of CPUs 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 PPL.
An rx4640 system is a 4-socket system and each socket can accept either a single-CPU or a dual-CPU processor module. This system may have up to 8 CPUs, 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.: CPU_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 CPU_SOCKETS=4 keyword in the HARDWARE_ID field. This license could be loaded on any system with 1 to 4 sockets. The number of CPUs 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 CPUs, you would need to purchase additional PPL units.
This chapter provides details about the tasks involved in managing software licenses. Topics covered include:
In addition, this chapter contains a clarification about using logical name LMF$DISPLAY_OPCOM_MESSAGE (see Section 4.7).4.1 Preparing for License Registration
To license and use many software products on the OpenVMS operating system, follow at least these four steps:
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 (an OpenVMS operating system license, for instance), 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.6.2 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 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 Database Location
If you move the 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.
HP recommends you back up the License Databases after every modification.
| Previous | Next | Contents | Index |