Centralized Licensing Facility processing

The License Management System (LMS) Centralized Licensing Facility (CLF) implementation provides a single server administration and distribution for all license types. LMS manages the execution of BMC products regardless of where they reside within an enterprise.

LMS 3.0, 3.1, or 4.0 is required in order to support the BMC mainframe product licensing wherein you purchase a certain number of MSUs, either for one location within your enterprise (site) or for your entire enterprise. You are free to deploy these MSUs in any way you choose, across any number of CECs or LPARs.

LMS 4.0 is fully compatible with LMS 1.0, 2.0, 3.0 and 3.1 license certificates. License certificates obtained for earlier releases of LMS can be imported into a LMS 4.0 server and distributed to LMS clients. Hence new certificates are required only if you are changing from older license types to the new product/MSU type of license and the new license certificates are required for product/MSU licensing.

Utilization versus size

The CLF feature of LMS supports two distinct types of sub-capacity licensing:

1. By adding the capped LPARs sizes for each product and option chosen by you to execute on the LPARs together.
2. By adding the current rolling 4-hour average MSU utilization values from each LPAR chosen by you to run a particular product or option together.

In each of these cases, LMS compares the sums created above to the number of MSUs licensed for each product and/or option. As long as the sums remain at or below the licensed number the product or option is allowed to execute. In the first case, if the sum of the LPAR sizes exceeds the licensed value the products or options enter a 14-day LPAR size grace period. In the second case, if the sum of the rolling 4-hour average MSU utilization values exceeds the licensed value, products or options enter a 14-day LPAR utilization grace period. A new license certificate is required in either case to exit these grace periods.

If you have chosen utilization, then the size of the LPARs is of no consequence and are not checked by LMS. Your LPARs may all be uncapped in this mode of operation. Uncapped LPARs are supported and are expected in most installations.

You may choose either utilization or size licensing for your enterprise, but whichever you choose must be used on all LPARs connected to the same CLF server. You choose utilization by specifying LPAR_MODE(UTIL) in the LMSINIT parameters for all client LPARs. You choose size by specifying LPAR_MODE(SIZE) in the LMSINIT parameters for all client LPARs. You may choose either, but you must be consistent among all clients connected to the same server. LMS does not check to ensure that all clients are using the same mode so you must be certain that you specify the same value in every LMSINIT SYSIN data set.

Because all client LPARs in a CLF environment are connected via TCP/IP, they need not be on the same CEC. The CECs can be any "z" mainframe. And all supported releases of z/OS can be used and they need not all be at the same release level (only z/OS is supported by CLF: MVS/ESA and OS/390 are not supported in this mode).

LPAR_MODE(SIZE) is available in CLF because LMS 3.0. LPAR_MODE(UTIL) is new with LMS 4.0. The default value if this parameter is not specified or is specified as a null value is LPAR_MODE(SIZE).

The license certificates are the same for both of these modes. These certificates specify CERTVER<03.00.00>, a product or option section, a CPU section and an LPAR section which contains only the number of MSUs you have licensed for the product or option. You can only license fewer MSUs for an option than for its product.

For LPAR_MODE(UTIL), it is the rolling 4-hour average MSU utilization which is extracted from each LPAR and sent to the LMS server for processing. The server adds together these values on a product or option basis (that is, only values from LPARs you have chosen for a product or option are added together) and the sum is compared to the value on the license certificate for that product or option.

LMS does not calculate the current rolling 4-hour average MSU utilization values but instead obtains these values from z/OS via IBM supported system calls. Spikes in utilization are not reported as the current value but are averaged with all the values for each 5-minute period over the previous 4 hours and are, therefore, averaged out and often do not increase the final sum (assuming for some 5-minute periods the utilization is less than the average value). Also, if following an IPL when z/OS does not have values for the previous 4 hours, it still divides the utilization sum by 481. Hence a significant utilization immediately following and IPL (for example, extreme CPU utilization during IMS start-up) is under-reported and does not cause the total utilization to be inordinately large. The utilization is accurate 4 hours following an IPL.

Requirements and coexistence of LMS releases

You may implement the CLF option of LMS 4.0 on an LPAR-by-LPAR basis whilst retaining your older licensing releases, or LMS 4.0 without CLF on other LPARs.

When CLF is employed, all LMS clients and the LMS server must be at the same release level. Error messages are displayed on the system console and on the client or server SYSPRINT data set if mismatched versions of LMS are detected. The LMS 4.0 client will abend with a User 319 abend code if the client detects that it has been configured to communicate with a release of the LMS server which is not 4.0. The LMS 4.0 server will display messages on the console and on the server SYSPRINT if it detects that an LMS client, not at the 4.0 release level, is attempting to connect to it.

You must ensure that all client LPARs which are connected to the LMS 4.0 CLF server are at the 4.0 release level.

Prior to implementing CLF, please contact BMC and obtain all current PTF maintenance available for LMS 4.0. In this way you will be assured of the most stable and correctly executing product.

If you have only CERTVER<01.00.02> license certificates, connectivity between LMS clients and the LMS server is required only in order for LMS to transmit these certificates to the LMS clients. Once a particular configuration has been activated and the certificates transmitted, the LMS server can be brought down. The LMS clients will execute on their own without server connectivity. These LPARs can be IPL’d (and LMSINIT run again) without server connectivity because the license information is stored locally on each client checkpoint data set.

However, when you have imported LMS 3.0 certificates (CERTVER<03.00.00>) and have distributed these to the LMS clients, connectivity with the server is required at all times. If communication between a client and the server is lost, then products licensed with CERTVER<3.00.00> will enter a 72-hour server grace period. This grace period will automatically exit when connectivity is restored.

Components

The major components involved in the CLF implementation of LMS 3.0 are:

• Client LPAR
• Server LPAR
• ISPF interface

Each of these components is described below.

Client LPAR

A client LPAR is a logical partition running one or more BMC products and containing an LMS client address space active within it. If client/server mode is not chosen when LMS is installed, the result is each client LPAR contains LMS code identical to LMS 2.0 and no address space is consumed. Only in CLF mode is a long-running address space required on each client LPAR.

Server LPAR

One LPAR within your location is designated a server LPAR and runs the LMS server program. The server executes as long-running address spaces within the LPAR. The LMS server can run in an LPAR which is also running BMC products, and thus, that LPAR is designated both as a Client LPAR and a Server LPAR.

ISPF Interface

All user access to the LMS server occurs via an ISPF interface. ISPF runs under a TSO session and that TSO session can exist on any LPAR in your environment. Because TCP/IP is used to communicate between the ISPF user interface and the LMS server, no requirement exists that the TSO session be active on the same LPAR as the server or any of the LMS clients.

Server connectivity

The following rules govern the connectivity requirements between the LMS server and the LMS clients:

• LMS clients running in non-CLF mode have no connectivity requirements as there is no server program involved.
• LMS clients running in CLF mode initiate all connections with the LMS server. Thus, the client startup parameters include the IP name (or IP address) and port number of the LMS server. The addition of these parameters differentiates a client running in non-CLF mode from one running in CLF mode.
• LMS clients running in CLF mode, but which have only LMS 1.0 or LMS 2.0 certificates, only require connectivity to the LMS server once in order to receive their license file. These clients write information to a local checkpoint dataset and the data from this dataset is used for all subsequent LMSINIT processing. Only a customer- initiated change, a Dynamic CPU Upgrade (CUoD), or an LPAR size change requires reconnecting to the server. Operating system IPLs and their subsequent LMSINIT execution do not require connection to the server.
• LMS clients running in CLF mode and licensed via a Product/MSU (CERTVER<03.00.00>) license must remain co nnected to the LMS server at all times. Loss of this connectivity causes the client to enter a server grace period. Exit from this grace period is automatic as soon as server connectivity is reestablished.

Server licensing

The scope of an LMS server encompasses the LPAR on which the server is running and all client LPARs connected to that server. There is no physical implication to this definition; it is a logical construct only. A single physical location (for example, a computer room) can be divided into multiple logical server sites due to mandated security requirements that preclude the interconnection of all client LPARs to a single server LPAR. A separate LMS server is, of course, required for each logical site.

Each CLF certificate contains a server section. Within each exists the physical identification of the LPAR on which the server is allowed to execute. This identification takes the form of the concatenation of CEC_SERIAL, LPAR_NAME, and OS_NAME (i.e., CVTSNAME). The server can only run on this specified CEC/LPAR/OS. No backup server capability exists. If the CEC/LPAR/OS is not available, create a Support case at Support Central to receive a temporary server license. Make sure to select the For entitlement and license key/password issues, please check here check box. BMC products execute in server grace mode until connectivity with the server is reestablished.

In order to determine exactly what the SERVER_ID<> on a CLF certificate must specify, you must execute the LMS server (LMZMAIN) on the LPAR you want to designate as the "server" LPAR. The server's SYSPRINT data set contains a message with the information you must communicate to BMC Support for them to correctly construct the SERVER_ID<> parameter.

User functions

The following topics describe those functions available if the CLF facility of LMS is implemented. Each of these functions is presented via TSO/ISPF. See Using-the-LMS-Centralized-License-facility for more information about using these functions.

Specifying Server IP Name or Address

Your DNS (Domain Name Server) is used to convert a server name to its IP address. You have to update the DNS with these values if you wish to use a server name. No update is required if an IP address is used. You must ensure that physical and logical IP connectivity is required between each of the client LPARs and the server LPAR. Logical connectivity includes ensuring that all routers and firewalls involved in the connection be made to pass LMS connection requests.

Logging On to the Server

You must enter your RACF (ACF/2 or TOPSECRET) USERID and password to access the LMS server. Optionally, a group name and new password can be entered. An administrator can limit access to the server via a Facility Class Entity that associates USERIDs with LMS server images. Each server image has a unique entity name allowing users to access one server, but not another one. When RACF is used, if the administrator has not added the Facility Class Entity, then any user with a valid USERID and password can access the server.

Protection is maintained such that two users are not allowed to perform update functions resulting in the integrity of the server tables being jeopardized. In order to determine exactly what the RACF (ACF/2 or TOPSECRET) facility class entity should be, you need only to execute the LMS server (LMZMAIN) on the LPAR you wish to designate as the "server" LPAR. The server's SYSPRINT data set will contain a message which shows exactly what you must code as the facility class entity in order to protect execution of the LMS 4.0 server. Userids or Groups must be granted ACCESS(READ) to this entity.

Logging Off from the Server

You can log off manually from the server. Logoff is also performed automatically by the server if no activity on the ISPF front-end occurs within a 15-minute period. In-flight configuration processing may be lost upon automatic logoff, and you are warned of pending configuration processing upon manual logoff.

Maintaining Logging Parameters

LMS contains a logging facility, primarily for debugging, but useful for other historic research purposes as well. You can start and stop this logging and can swap from one log file to another. You can also assign a log level that specifies how much log data is written. Logs are VSAM ESDSs defined automatically by LMS using customer supplied parameters, that is, name, volume, or SMS parameters. Currently logs can only be viewed from a batch report program, not from ISPF.

Maintaining Grace History Information

LMS supports an optional Grace History File where you can see in one place, a list of all your licensed products and see if and when any of them have entered any of the 14-day grace periods. Information from all connected LPARs can be contained in this one data set.
No automatic facility exists for browsing this file but you can export it via IDCAMS to a sequential data set or you can invoke BMC File-Aid product to browse the data itself.
A set of functions exists within LMUSER to open, close, and rename this data set.

Specifying the License File

You can add and delete license files and can query a list of currently defined files. Each license file is a VSAM KSDS and is updated only by the import process of the LMUSER. The LMS 2.0 import program has been updated for LMS, but is used as-is by the server program. Setting emergency passwords, disaster recovery mode, and logging levels are performed directly by the server against the LPAR definitions and are not recorded in the license files.

Importing License Certificates

Contracts Password Administration team sends license certificates as email attachments. You can import license certificates by completing the following steps:

1. Save the attachment as a file on the PC.
2. Cut and paste the attachment into a file on the mainframe.
3. Access the server.
4. Invoke the function to send the certificate to the server for import to a license file.

The license certificate must reside on the LPAR from which you are executing the TSO/ISPF LMUSER facility. This LPAR may or may not be the LPAR on which the LMS server is running.

Receiving an Import Report

The report program generated by the license import facility can be saved to a file or can be transmitted to the ISPF user requesting the import. You can scan the report and make note of any errors that occurred. For some certificate errors, we must send you the certificate again. To report a certificate error, create a Support case at Support Central.

Adding a Configuration Name

You can add a name of a new configuration and can use that name in subsequent configuration changes. Multiple configurations can exist concurrently, but only one can be active, that is, transmitted to client LPARs.

Cloning an Existing Configuration

You can clone an existing configuration under a new configuration name. All LPARs, license files, and associations between products and options and LPARs are copied to the new configuration.

Verifying a Configuration

You can request that a configuration be validated to ensure that the specifications in that configuration do not violate what the license certificate dictates.

Assigning Active Status

You can assign one configuration to active status. This must be done before the configuration is deployed to client LPARs. Only one configuration can be active at a time. A previously active configuration becomes inactive when a new active one is assigned. Previous configurations are maintained so that a fallback facility exists whenever a new configuration is found to be in error.
You decide when you want to deploy a new configuration to your client LPARs, by assigning an active configuration status. This deployment involves the transmission of license information to each connected LPAR, which happens within 30 seconds for all connected LPARs. LPARs coming online later receive the new configuration as well. If a client LPAR connects to the server and if its size or utilization does not match the size contained in the current configuration, an error is generated and the new LPAR enters a 14-day grace period.
An administrator must manually intervene to correct the size or utilization discrepancies. There is no requirement that the administrator be logged onto the server at the time that an LPAR connects. The process of notifying the user may be problematic because he may not even be at work when this connection occurs. The administrator should ensure that all LPARs that can connect, have connected, before logging off from the server.

Defining LPARs

You can query a list of all connected client LPARs, add new LPARs, and delete existing ones. Each LPAR is shown with its CEC_SERIAL, LPAR_NAME and OS_NAME, the size of the LPAR, plus any descriptive information as well. The size is the defined capacity or capped capacity of any LPAR running z/OS or z/OS-e. Or the size is the CEC capacity when either z/OS or z/OS-e is not running. In addition, the LPARs current MSU utilization is shown as well whether the LPAR mode is size or utilization.
When an LPAR definition is added manually, it is because the administrator is pre- defining a client LMS and the LPAR is not already active or is not running the client program.
When that LPAR becomes active, either the pre-defined entry is used (all key values match), or a new entry is added. You must manually detect that an LPAR you thought you previously added has become active. However, since one or more of the key elements did not match, the server assigned it as a new LPAR entry.
If a pre-defined LPAR becomes active and the size of that LPAR does not match the size you entered, the real LPAR size is used and the size you entered is discarded.

Querying Product/Versions

You can query a list of all BMC products maintained by the server. New products can be added only by importing a certificate containing valid product specifications. You cannot add products on your own. To obtain a license certificate, create a Support case at Support Central. Make sure to select the For entitlement and license key/password issues, please check here check box. The product list contains the names (both short and long names) and version of the product, the dates for which each is valid, any special access granted to the product, and the number of MSUs purchased. Options to each product can be displayed as well, but if an option is missing even if you thought you had purchased the option, a new certificate must be transmitted.

Associating Product/Version to LPAR

The administrator must associate a product/version for each product/option licensed by MSUs to one or more defined LPARs. Before a product/version can run on a client LPAR, it must be associated with that LPAR and a license definition must have been sent to the client LMS.

LMUSER tutorial

The following is a step-by-step tutorial of one of the most common functions you will perform using the ISPF EXEC LMUSER.
This tutorial will take you through the process of importing and activating a new license certificate from BMC . Other tutorials may be created in the future describing other LMUSER functions.

Accessing the ISPF User Interface

You may invoke LMUSER from any ISPF command line and the BMC LMS Logon screen is displayed.

On this screen you must enter the Host Name or Host Address and the Port Number of your CLF server. You must specify whether you are using IPv6 (Y or N). You must enter your UserID and Password.

Some common mistakes:

• When the Host Name of the server is changed, the Host Address must also be cleared (if one is shown) , otherwise the address will be used and not the new name.
• When the Host Address of the server is changed, the Host Name must also be cleared (if one is shown) otherwise a conflict between name and address will occur.

You will then be presented with the ISPF Interface Main Menu screen where you may execute each individual function.

Main Menu Screen

User Interface Main Menu Screen

Execute the following steps in the order specified to import and activate a new license.

1. Select Option 1 (Configure) and then select an existing configuration from which to clone a new configuration.
2. Select Option 2 (Define) and then either select an existing license file or define a new one.
3. Select Option 3 (Import) and then import your new certificate and check the results from this import.
4. Select Option 5 (Product) and then associate all of your products and options to the LPARs on which they are to be licensed.
5. Return to Option 1 (Configure) and activate the new configuration.

Each of these steps is described in detail below.

Option 1 Configure

Configuration Maintenance Screen (Part 1 of 2)

There is only one configuration shown in this example, the DEFAULT CONFIGURATION which is created automatically by LMS. As you create more configurations they will be shown in this list as well. You will probably want to select the most current configuration and make your changes to that configuration. You can choose any configuration you want, however.

Select this configuration and press Enter. This configuration is now shown at the top of the screen and is marked as CURRENT ACTIVE. Type a C to the left of this configuration and overtype the name with the name you want to use for your new configuration.

Configuration Maintenance Screen (Part 2 of 2)

The CLONED CONFIGURATION is shown as active and is named at the top of the screen. Press PF3 to go back to the main menu and select Option 2 (Define). You will see the License File Maintenance screen.

Option 2 Define

License File Maintenance Screen (Part 1 of 3)

You must type the name of a new license file because none currently exist. Type an N in the blank line under Data Set Name and then type the license file name. Press Enter. You will see the License File Maintenance screen.

License File Maintenance Screen (Part 2 of 3)

You may type more license file names, but normally you will have only one. You must select this file by typing an S to the left of it and pressing Enter. This name will now appear at the top of the screen.

License File Maintenance Screen (Part 3 of 3)

Notice that the name of this license file appears at the top of the screen. Press PF3 to go back the main menu and choose Option 3 (Import).

Option 3 Import

Import License Certificate Screen

When you press Enter, import will proceed. Wait until the import has completed and you will be presented with the Display Import Results Screen.

The cursor will be placed in front of your report data set name. Type a V to view the contents of this data set on your terminal and press Enter. You will see the View License File Screen.

View License File Screen

Note the message "WLM660I CERTIFICATE IMPORTED - NO ERRORS OR WARNINGS". This message indicates that you can proceed. If you receive an error message other than this one, you must examine the remainder of the report looking for the error messages that describe the error. Most likely, the SERVER_ID value will be incorrect and will be flagged as such. If this is the case, create a Support case at Support Centralto request them to rectify the SERVER_ID and send you a new license. The value required for SERVER_ID can be found in the SYSPRINT data set of the CLF server which you are running.  Make sure that you provide the correct value.

Press PF3 to exit viewing the import report and return to the import results screen. Pressing PF3 twice more returns you to the main menu where you will choose Option 5 (Product). You will see the Product / Option Maintenance Screen

Option 5 Product

Product / Option Maintenance Screen (Part 1 of 2)

To expand and view the option(s) available for a product, place an E next to that product and press Enter. To view all options/LPARS available for all products, place an EA on any table row and press Enter.

To select a product or option for further processing, place an A beside each product or option you want to associate and press Enter. You will see the Product Associations Screen. A list of all LPARs currently defined to the server is displayed.

To select a product and its related options for further processing, place an AP next to each product you want to associate and press Enter. You will see the Product Associations Screen. A list of all LPARs currently defined to the server is displayed.

Placing a / next to Propagate LPAR Associations will process all A and AP commands using the same set of LPARS that will be selected on the Product Associations Screen. The product association screen will appear only one time for all products and options selected.

If you do not place a / next to Propagate LPAR Associations you will be presented with the Product Associations screen for each product and related option selected.

Product Association Screen

This screen displays a list of all LPARs which are currently defined for the selected configuration.

Product Associations Screen

If you did not place a / next to Propagate LPAR Associations on the Product / Option Maintenance Screen you will be presented with the Product Associations screen once for each product and related option selected previously. Type an S to the left of the LPAR(s) you want this product to run on and press Enter. You will be shown this screen again with the word ASSOC on each line you selected. Press PF3 to return to the association panel for the next product or option which you have chosen. Select the LPAR(s) you want and press Enter for each. Press PF3 when you want to go to the next product or option. When you are finished, press PF3 again and you will be presented with the Product/Option Maintenance Screen.

If you typed a / next to Propagate LPAR Association on the Product / Option Maintenance Screen, the product association screen will appear only one time for all products and options selected. Type an S to the left of the LPARs you want this product to run on and press Enter. You will be shown this screen again with the word ASSOC on each line you selected. Press PF3 and you will be presented with the Product / Option Maintenance Screen.

Product / Option Maintenance Screen (Part 2 of 2)

Notice that under each product and option you selected, the LPARs on which these are to be licensed is shown. Notice also that the type of licensing (LPAR size or LPAR Utilization) is shown on the right.

Press PF3 to return to the main menu and choose Option 1 (Configure) again.

Option 1 Configure

Type a V next to the configuration you have been working on and press enter. This causes LMS to verify that the configuration is valid. With LPAR MSU Utilization licensing, the reason a configuration would not be valid is if the current sum of the rolling 4-hour average utilization values of the LPARs you chose exceeded the number on the license certificate for one product or option. For LPAR Size licensing, the configuration would not be valid if the current sum of the sizes of the LPARs you chose exceeded the number on the license certificate. You must return to the LPAR association screen and remove at least one LPAR from the product or option. The current utilization and size of each LPAR is shown, so it is a matter of adding up these numbers and comparing the results to your license certificate.

If no errors are reported, you may continue by typing an A next to the configuration you have been working on and press Enter. If the verification process detected an error, you will NOT be allowed to activate the configuration.
You can exit to the main menu by pressing PF3 and exit LMUSER.

You have completed the functions required to clone a new configuration, define or select a license file, import a new certificate, associate your products and options to LPARs and activate the new configuration.

Within 30 seconds the client LPARs on this configuration will begin to receive their new license information. This may take a couple of minutes to complete but when it has the new license is active.

LMS Client Address Space

When an LMS client is running in CLF mode (that is, SERVER_NAME() or SERVER_ID() is specified in the LMSINIT parameters), a long running address space is created. LMSINIT does not terminate upon completion of its processing, but invokes the mainline program of the LMS client implementation. This mainline initiates communication with the LMS server.

Emergency Passwords in a CLF Environment

Emergency passwords are obtained from BMC whenever a situation has occurred which precludes normal license processing. To obtain these passwords, create a Support case at Support Central. Make sure to select the For entitlement and license key/password issues, please check here check box. An emergency password obtained via Frontline remains in effect for a total of 7 days starting from the day after the day the password was obtained. In the CLF environment emergency passwords can only be applied by adding an EMERGENCY() parameter to the LMSINIT SYSIN data set and stopping and restarting the LMS Client. There is no method for applying an emergency password to the license file.

Disaster Recovery in a CLF Environment

Different disaster recovery scenarios lead to different behavior of LMS. If the disaster site exactly replicates the original site then LMS will operate with no manual intervention by customer personnel. This replication must include LPAR names and sizes (assigned by the Hardware Management Console), the system names and the LMS subsystem names. TCP/IP addresses must be identical and all DASD volumes must be available at the disaster site.
These will probably not all be identical at both sites so some intervention will be required at the disaster site.
The simplest method for insuring BMC product execution is to apply an emergency password to each LMSINIT client at the disaster site. Since these passwords can be obtained from Frontline, little time will be spent applying them. And there is no need to even execute the LMS server at the disaster site if emergency passwords exist in the LMSINIT client SYSIN data set.

If, however, you want to run the LMS server at your disaster site you must insure that the checkpoint data set and the license file(s) from your main site be available to the server. You need not transport the server log, VSAM SMF data set or the history data set as these will be created automatically by the server and they are output only data sets so there is no need for them to be read by the server. Each client may or may not require its checkpoint data set. If any of the variables which define an LMS client (LPAR name, system name and subsystem ID) differ at the disaster site then the LMS client will not process data on its checkpoint data set.

If the TCP/IP address of the server LPAR differs at the recovery site, then each LMSINIT client’s SYSIN data set must be changed to reflect the different server address.

Differences in the three client definition values will cause the LMS clients to not allow any product execution until these differences are resolved. Of course an emergency password would alleviate this situation and all BMC products would be allowed to run.

If you correct the TCP/IP address of the server than it will transmit license information to each client which connects with it as follows.

CERTVER<01.00.02> CEC/MODE and CERTVER<02.00.00> sub-capacity licensed products will be allowed to run for a 14 day grace period.

CERTVER<03.00.00> licensed products will not be allowed to run until LMUSER is invoked and the different LPARs selected for the desired products. If the sum of the sizes or utilizations of the LPARs does not exceed the licensed amount then no grace period will be entered. If the sum of the sizes or utilizations of the LPARs does exceed the licensed amount then the cloned configuration will not activate and the products will not run. You may have to choose a fewer number of LPARs to run your BMC products in this case.

You may not define a new license file at the disaster site intending to import your license certificates into it unless you obtain a new certificate carrying the correct LMS server identification. The LMS server will, however, read existing license files and transmit their contents to the LMS clients even though the server parameters which created these files is no longer valid. The 14 day grace period of the clients insures no contract violation in this case.

It is extremely important to recognize that you must not bring back to your main site the checkpoint data sets from the disaster recovery site after the disaster has passed. These may contain 14 day grace period indications which if these files were returned to the main site would necessitate a complete reimport of new license certificates obtained from BMC.

Disaster Recovery Testing in a CLF Environment

Disaster recovery testing differs from a real disaster by the fact that it is planned for in advance and requirements for LMS can be accounted for before the actual test. In many cases existing hardware is used for the disaster test but the CEC(s) involved may be increased in size via a CBU operation performed on the Hardware Management Console. Since BMC products were originally licensed on the CEC(s) before the CBU, they will remain licensed after the CBU albeit with a possible 14 day grace period.

Depending upon the type of licenses you have, different 14 day grace periods will be entered when LMS detects that a CBU has occurred.

CERTVER<01.00.02> CEC/MODEL licenses may enter a 14 day CEC MODEL grace because the model number of the CEC may have changed if additional CPs are brought online.

CERTVER<02.00.00> sub-capacity licenses may enter a 14 day LPAR size grace if the LPARs increase in size due to the CBU. If you have defined capacity LPARs that these will not increase in size even when a model change occurs unless you change the defined capacity limit at the same time you perform the CBU.

You must be aware that once any 14 day grace period occurs that the only way to exit this grace is to obtain entirely new certificates from BMC and you must import anew into LMS. This is true even if subsequent to the initial CBU event that you revert your CEC to its original model and size. Once a 14 day grace has been entered it cannot be executed without new certificates from BMC.

Using LMBDISTR to Set Disaster Recovery

If your disaster recovery procedures include setting the disaster recovery indicator in your license files at the disaster site, it may be more convenient for you to continue doing this even when you have installed LMS 4.0 CLF.
Program LMBDISTR must be used in place of the LAU to set disaster recovery. In the CLF mode, the license file is NOT used to contain the disaster recovery indicator. This setting has been moved to each client's checkpoint data set. Therefore, it is this data set that you must supply to program LMBDISTR.

If you have taken multiple LPARs to your disaster site you must run LMBDISTR on each unique LMS client checkpoint data set. If you share your checkpoint data set among multiple LPARs you need to run LMBDISTR only once. It will add disaster recovery to each LPARs section of the checkpoint data set.

Executing LMBDISTR
The following is sample JCL used to execute LMBDISTR:

You may execute this program under TSO by manually allocating the DDNAME LMSCHKPT to your client checkpoint data set and by calling LMBDISTR.

Messages displayed by LMBDISTR

LMBDISTR writes messages to the system console and to the JOBLOG indicating the status of its execution.

LMB100I DISASTER RECOVERY PROCESSING HAS STARTED
LMB101I DISASTER RECOVERY PROCESSING HAS ENDED
LMB102I DISASTER RECOVERY SET FOR SITE nn THROUGH mon day,year
LMB103I DISASTER RECOVERY ALREADY SET FOR SITE nn THROUGH mon day,year

Message LMB102I indicates normal execution. If you re-run LMBDISTR you will receive message LMB103 indicating that disaster recovery is already set.

Use of License Administration Utility in a CLF Environment

In all releases of LMS, when the CLF environment is not used, the ISPF application known as the License Administration Utility (LAU) is employed by the customer to perform the following functions:

1. Define and initialize license files
2. Import certificates into license files
3. Submit JCL to run report programs
4. Set disaster recovery processing on/off
5. Set emergency passwords in the license file

When CLF is used, function #1 and #2 (defining license files and importing certificates into them) should not be performed by the LAU. Instead, the ISPF utility named LMUSER provides these functions for the CLF customer. Although the LAU can be used if no LMS certificate exist, BMC does not recommend doing so. Instead all license file processing should be performed by LMUSER. The LAU is not capable of importing an LMS certificate into a license file.

Submitting JCL to run the licensing report programs can still be performed via the LAU even in a CLF environment.

Disaster recovery and emergency passwords are no longer supported in the same manner as in previous LMS releases and the LAU should not be used to set these values into the license file. See the sections in this document which discuss disaster recovery and emergency passwords.

The Grace History File

An optional facility exists that is the creation of a history data set containing 14 day grace information about products and options. This information includes an indication of when these products were first licensed at your installation, and if they enter any of the 14 day grace periods, and indication as to when they entered the 14 day grace and an indication as to when that grace will expire. You can use the information in this data set to insure yourself that the products and options you have purchased are validly licensed.

Grace History collected by the client LMS systems can be written to VSAM files maintained by the clients. Alternatively you can have the history data sent via TCP/IP to the server where a common history file resides. In this way you have the information about all of your LPARs centrally maintained for ease of use.

In order to request that the history data be transmitted to the server, change the parameter in the LMSINIT SYSIN data set from:
HISTORY_FILE(LOCAL)
to
HISTORY_FILE(SERVER) or
HISTORY_FILE(BOTH)

If you specify HISTORY_FILE(SERVER) then the history data will be transmitted to the server and not stored locally. If you specify HISTORY_FILE(BOTH) then the history data will be both transmitted to the server and stored locally.

If you specify HISTORY_FILE(SERVER) in an LMSINIT SYSN data set then you do not need to specify any of the other history file parameters in that LMSINIT. If you specify

HISTORY_FILE(BOTH) in an LMSINIT SYSIN data set, then you must also specify the history parameters as you would with HISTORY_FILE(LOCAL).

In order for the LMS server to store the history file data it must have parameters added to its SYSIN data set describing this file. These parameters are:

HISTORY_DSNAME(datasetname)
HISTORY_TRACKS(nnn)
HISTORY_VOLSER(volser)
HISTORY_STORCLASS(classname1)
HISTORY_MGMTCLASS(classname2)
HISTORY_DATACLASS(classname3)

These parameters are described in detail in the section titles Server Start-Up Parameters, History File.

Automatic Restart Management

LMS Centralized Licensing Facility supports IBM’s Automatic Restart Management (ARM) facility. ARM will automatically restart a failing job or started-task a certain number of times which allows a customer to employ a “lights out” approach to running their z/OS environment.

Both the CLF clients and the CLF server can be configured to implement ARM support. Two parameters have been added to the client and server //SYSIN data sets which control ARM support. These are discussed below.

Before enabling ARM in LMS, you must ensure that you have provided all the necessary z/OS facilities required for ARM to execute. The following IBM manuals may be helpful in this regard:

• z/OS VvRr.0 MVS Sysplex Services Guide
• z/OS VvRr.0 MVS Programming Sysplex Services Reference
• z/OS VvRr.0 MVS Setting Up a Sysplex

For instance, the second manual listed above contains a list of all return/reason codes that can result from issuing the IXCARM macro. You should have this manual handy in case LMS indicates that an unexpected return/reason code has occurred. For instance, if you have not catalogued an automatic restart management couple data set, LMS will report that is has received a return code of X’0C’ and a reason code of X’0160’ from IXCARM TYPE=REGISTER.

You may add your own policy information which controls the ARM processing for the element names you choose. You may choose the number of times a job is to be restarted in the number of seconds that can elapse after a restart but before the restarted job indicates to z/OS that it has completed its initialization and is ready to continue processing. You should allow at least the same number of seconds as your system default. Normally, CLF clients and server will initialize quite quickly (within 10 seconds) but if there is a delay in your environment, this delay should be reflected in the value you choose for the policy.

You must add “SPIN=UNALLOC” to the //SYSPRINT DD SYSOUT=* DD statement in the JCL or the PROC that invokes both the CLF client or server. If you do not do this, then you will not be able to see the SYSPRINT data from each execution of the client or the server. You will see only the last execution. This DD statement will appear as follows:

The parameters for invoking ARM are the same for the CLF client (i.e. LMSINIT) and the CLF server (i.e. LMZMAIN). These parameters are:
ARM(YES|NO)

Specify ARM(YES) if you want Automatic Restart Management to be activated. Specify ARM(NO) or ARM() if you do not. ARM(NO) is the default if this parameter is omitted.

ARM_ELEMENT_NAME (xxxxx... . .xxxxxx)

Specify a sysplex unique 1-16 character name to be associated with this CLF client or server. This name must be different for the server and for each client. We strongly recommend that you use the following naming convention:

Bytes 1-3 C’LMS’
Bytes 4-7 **your SMF system ID**
Bytes 8-16 Any name of your choice but it should indicate “client” or “server”

You may choose your own names but insure that they are all unique.

If you wish to test ARM you should bring up a CLF client or server and then issue the following command from the console or from an SDSF command line:

Replace *jobname* with the name of the client or server JOB. The job will be restarted automatically. When you subsequently stop the client or server by issuing the STOP command the job will end. Browsing via SDSF will show two instances of the SYSPRINT data set within one single job. These two instances represent the two executions (one ending via the CANCEL command and the other ending via the STOP command).