Methods to enable disaster recovery
Method 2: DR mode batch utility
Using the LMBDISTR utility, you can update your checkpoint data sets to indicate DR mode is on. The following skeleton JCL for using the utility:
//DISASTER EXEC PGM=LMBDISTR
//STEPLIB DD DSN=**Your LMS load library dsname **,DISP=SHR
//LMSCHKPT DD DSN=**2nd client checkpoint dsname **,DISP=SHR
//DISASTER EXEC PGM=LMBDISTR
//STEPLIB DD DSN=**Your LMS load library dsname **,DISP=SHR
//LMSCHKPT DD DSN=**3rd client checkpoint dsname **,DISP=SHR
//DISASTER EXEC PGM=LMBDISTR
//STEPLIB DD DSN=**Your LMS load library dsname **,DISP=SHR
//LMSCHKPT DD DSN=**4th client checkpoint dsname **,DISP=SHR
//DISASTER EXEC PGM=LMBDISTR
//STEPLIB DD DSN=**Your LMS load library dsname **,DISP=SHR
//LMSCHKPT DD DSN=**5th client checkpoint dsname **,DISP=SHR
.
.
.
//DISASTER EXEC PGM=LMBDISTR
//STEPLIB DD DSN=**Your LMS load library dsname **,DISP=SHR
//LMSCHKPT DD DSN=**20th client checkpoint dsname **,DISP=SHRRestart the LMS environment by issuing the following MVS modify command:
F cmscname,LMRESTRT CLIENT
Method 3: LAU ISPF utility
- Enter the LAU utility. (If you do not have this set up, please see the instructions on running LMSPREP found at Creating a License File).
- Enter Option 6: Disaster
- Select the site for which you wish to enable disaster mode.
- Confirm your choice.
Restart the LMS environment by issuing the following MVS modify command:
F cmscname,LMRESTRT CLIENT
Default member: LMCLALL (client)
FUNCTION
Description: FUNCTION is used to define a new, edit, or delete a SUBSYSTEM_ID value.
Values: CREATE is used to define a new SUBSYSTEM_ID value for the first time. CREATE specifies that this SUBSYSTEM_ID value should be added to the operating system table of subsystems. LMSINIT will not process a CREATE request if the value specified for SUBSYSTEM_ID already exists in the subsystem table.
UPDATE is used to define a new SUBSYSTEM_ID value for the first time or to change an existing SUBSYSTEM_ID value. Therefore, LMSINIT will process the UPDATE request for both new and existing SUBSYSTEM_ID processing.
DELETE is used to delete an existing SUBSYSTEM_ID value from the table of subsystems. LMSINIT will process the DELETE request only if the SUBSYSTEM_ID value names a subsystem already active in the subsystem table.
Default: none
Required: yes
SITE
Description: The specification of a site number is required for LMSINIT execution. This number (or numbers) tells LMSINIT which site(s) to load from the license file(s) into the license cache.
Values: three-digit number from 001 to 999
When specifying more than one SITE, a DD name must be provided for each SITE using the SITE_DD parameter. The DD must be CWLFxxxx, where CWLF0000 is the DD name for the first SITE, CWLF0001 is the DD name for the second SITE, and so on.
You must either code a CWLFxxxx DD statement corresponding to the SITE_DD parameter in the CMSC start-up JCL, or specify a LICENSE_DSNAME parameter in the LMCLxxxx member. While these parameters do not have to be specified together in a group, each of these three parameters must be supplied in the same order as the others. Therefore, the SITE, SITE_DD, and LICENSE_DSNAME parameters for the first SITE must be specified before the SITE, SITE_DD, and LICENSE_DSNAME parameters for any other sites. We recommend that you specify the SITE, SITE_ DD, and LICENSE_DSNAME parameters together.
If you only have one SITE then the SITE_DD parameter is not required. It will default to CWLF0000.
Example with one license file:
Example with two license files:
SITE_DD
Description: Specifies the DD name associated with the corresponding SITE and LICENSE_DSNAME parameters. See the description of the SITE parameter for details.
Values: CWLFxxxx
where xxxx is a number between 0000 and 9999
Default: CWLF0000
Required: Needed only when more than one set of SITE and LICENSE_DSNAME parameters is specified.
SUBSYSTEM_ID
Description: The value specified on the SUBSYSTEM_ID operand names the subsystem that this invocation of LMSINIT will process.
Values: This value can contain only uppercase letters and numbers.
Although the operating system allows subsystem names to contain lowercase letters and special characters, LMS does not because the subsystem name may need to be included in the DDNAME of a //CWIDSSSS DD DUMMY statement. Therefore, the value chosen for SUBSYSTEM_ID must also be valid in a DDNAME.
You must coordinate the use of the subsystem identifier, because duplicate names are not allowed, either within the set of License Management subsystems, or across all subsystems defined. Check with your systems programmer to ensure that the SUBSYSTEM_ID value you have chosen is not already in use.
Default: none
Required: yes
DEFAULT
Description: This operand defines whether this SUBSYSTEM_ID will be declared the default subsystem.
Values: NO|YES|FORCE.
Default: none
Required: yes
LICENSE_DSNAME
Description: Specifies the license file data set name to be used. Multiple LICENSE_DSNAME entries may be specified.
Default: none
Required: yes
EXIT_PROC
Description: Specifies the 1- to 8-character member name in SYS1.PROCLIB (or any appropriate PROCLIB), of the PROC which LMS automatically starts whenever an event occurs which drives the event notification exit. The events which will cause this PROC to be started are:
- A Dynamic CPU Upgrade (CPU Upgrade on Demand)
- A change to the defined capacity of the LPAR.
The first SMF interval to expire each midnight.
An example of this PROC is shown below. Code the PROC exactly as shown below, substituting only the name of the APF-Authorized Load library which contains the LMS load modules.
//EVENT EXEC PGM=LMSENMGR,PARM=&LMSSYS
//STEPLIB DD DSN=** Your APF Loadlib **,DISP=SHR
In LMS version 2.0 two messages were written to the system console for each product/option found on the checkpoint data set
These messages were “LMG042I Product xx Version xx Updated On Checkpoint File” and “LM6043I xx the xx Option of the xx Version xx Updated on Checkpoint File.”
These messages have been removed and have been replaced with a single message “LM5305I all products updated on the LMS checkpoint data set”.
This change significantly decreases the number of messages written to the system console each time the EXIT_PROC is invoked.
Required: yes
SERVICE_BUREAU
Description: You may specify SERVICE_BUREAU=YES or SERVICE_BUREAU=NO. If omitted, the default is SERVICE_BUREAU=YES. This operand controls the use of RACF (ACF/2 or CA-Top Secret) when multiple license files are used as input to LMSINIT.
If you have only one License File, you may ignore this operand. In a true service bureau environment [SERVICE_BUREAU=YES], access to a particular license file cache must be controlled by RACF so that users of BMC AMI products are restricted to using only the product set validly licensed for them.
A non-service bureau customer may want multiple license files but without the associated RACF security checking that would normally occur. By specifying SERVICE_BUREAU=NO, you can process multiple license files as if the data in them were all contained in a single file. That is, the requirement to define the license file names to RACF is eliminated.
Values: NO|YES
Default: YES
Required: no
SMF
Description: This parameter allows the user to specify whether or not the LMS should write SMF records.
Values: YES | NO
YES writes records to SMF
NO prevents writing records to SMF
Default: YES
Required: no
For more information and examples on the usage of SMF parameter, see zAdviser-parameters.
SMF_ID
Description: The value specified on the SMF_ID operand defines the SMF Record ID number to be used on all SMF records written by the License Management System. The SMF_ID must be a three-digit number in the range of 128 through 255.
If the SMF_ID is not specified, by default, the value is set to 241.
You must coordinate the use of SMF identifiers so that no duplicate numbers are defined to any program or system writing SMF records. Check with your systems programmer to ensure that the SMF_ID value you have chosen is not already in use.
SMF_LOGALL
Description: Specifying YES forces all license check-out and check-in to be logged to the SMF data sets regardless of the settings of the SMF_LOG parameters within the license file. This causes SMF logging indicators in the license file to be ignored.
Values: NO | YES
Default: NO
Required: no
SMF_SERVER
Description: When running in CLF (Consolidated License Facility) mode, specifying YES indicates that SMF data is to be sent to the server, and the server is to write out the SMF records.
Values: NO | YES
Default: none
Required: no
EMERGENCY
Description: LMSINIT has the ability to load an emergency license cache even if the license file is unavailable or has become corrupted. The value required on the EMERGENCY operand is obtained by calling BMC Support to request an emergency password.
- Remove all LICENSE_DSNAME statements from the LMS client PARMLIB member and submit the JCL.
- When a legitimate emergency password is present in the LMS client PARMLIB member, all BMC AMI products will be allowed to execute on the system.
Default: none
Required: no
CHKPT_DSNAME
Description: Required operand. License Management System requires a checkpoint data set to be available LMSINIT and to certain operating system exits at all times. This data set is created automatically by LMSINIT if it does not already exist, or it is updated if it does exist. You must specify the 1- to 38-character name of this data set, either using the parameters described here, or by a special DD statement in the LMSINIT JCL.
The user ID under which LMSINIT is run must have ALTER access to the security system (RACF, ACF/2, CA-Top Secret) entity named by this data set name. The IDCAMS utility is dynamically invoked to define this data set.
Default: none
Required: yes
CHKPT_VOLSER
Description: This parameter specifies the 6-character volume serial of the DASD volume on which the checkpoint data set is to reside. If it does not exist, your system installation defaults for VSAM data sets are used to determine the placement of this data set. You must ensure that any VOLSER you specify is consistent with the SMS class definitions that may also exist.
Default: none
Required: no
CHKPT_STORCLASS
CHKPT_DATACLASS
CHKPT_MGMTCLASS
Description: These parameters specify the names your installation has chosen to describe the allocation of this VSAM checkpoint data set. If specified, these parameters are used within the IDCAMS DEFINE control statements when the data set is created.
Default: none
Required: no
SITE_WARNING
Description: The value specified on the SITE-WARNING parameter specifies whether you want LMSINIT to complete with a return code of 4 whenever SITE records in a license file are skipped (YES), or you want LMSINIT to complete with a return code of 0 (NO). LMS 1.0 always completed with a return code of 4 when LMSINIT detected that there were SITE records in the license file that were not loaded because their SITE number was not included in the SITE() parameter. If you omit the SITE_WARNING parameter, this behavior will exist in LMS 4.0 as well. But, if you know that you are skipping SITE records, and you want a return code of 0 so that your automated operator program will detect this return code, then include the SITE_WARNING parameter and specify a value of NO. If this parameter is omitted SITE_WARNING=YES is used as a default.
Default: YES
Required: no
SUCCESS_CMD
WARNING_CMD
ERROR_CMD
Description: These three LMSINIT parameters define master console commands that can automatically be issued by LMSINIT. LMSINIT can complete with a return code of 0, a return code of 4, or a return code of 8 or greater. Each of these three conditions can have a unique console command associated with it. LMSINIT will issue the command that represents the current return code.
BMC does not supply any procedures to be started by these commands. It is the customer’s responsibility to ensure that any PROC specified in a command exists in an appropriate procedure library.
The examples below issue an Z/OS “START” command. But any valid operator command could be issued as well.
- If no command is specified for a particular return code value, then no command is issued when that return code occurs.
- Any, all, or none of the three return code conditions can have a command associated with it.
- Commands can be the same or different for each of the three return codes.
- The commands will be issued as if they were entered at the Master Console, and the Security (RACF, ACF/2 or CA-Top Secret) USERID will be the USERID under which LMSINIT is running. Ensure that this USERID has the appropriate authority to issue Master Console commands.
Rules for coding these commands follow:
- If the command contains blanks, then enclose the entire command in single (’) or double (") quotes.
- If the command contains blanks and single quotes, then enclose the entire command in double (") quotes.
- If the command contains blanks and double quotes, then enclose the entire command in single (’) quotes.
- The single or double quotes will be removed before the command is issued.
EMAIL_OPTION
Description: NONE indicates no e-mail messages are generated for any option. WARN indicates that e-mail messages are generated for options that are allowed to run, but a warning condition exists (for example, option within 14 days of expiration). FAIL indicates that e-mail messages are generated only if the option is not allowed to run.
Values: NONE | WARN | FAIL
Default: E-mail messages are generated for option warnings and failures
Required: no
EMAIL_PRODUCT
Description: NONE indicates no e-mail messages are generated for any product. WARN indicates that e-mail messages are generated for products that are allowed to run, but a warning condition exists (for example, product within 14 days of expiration). FAIL indicates that e-mail messages are generated only if the product is not allowed to run.
Values: NONE | WARN | FAIL
Default: E-mail messages are generated for product warnings and failures
Required: no
TCPIP_NAME
Description: By including this operand, you indicate that you want to activate the automatic e-mail notification facility.
TCPIP_NAME specifies the name of the TCP/IP protocol stack that is active on this CPU:
—If you are using IBM’s TCP/IP (release 3.2, 3.4 and above), then this name must match the name specified as TCPIPJOBNAME in the TCPDATA member of the TCPPARMS data set used to initialize TCP/IP. If you do not know what this name is, your mainframe network administrator will be able to find this name and tell you what it is.
—If you are using the Interlink Corporation’s TCPaccess TCP/IP (release 4.1 and above), then this name must match the SSN= operand on the EXEC statement in the procedure used to invoke the TCPaccess TCP/IP. If you do not know what this name is, your mainframe systems programmer will be able to find the TCPaccess procedure in the system PROCLIB and tell you what is coded on the SSN= operand.
Default: none
Required: no
MAIL_SERVER_NAME
Description: Although this operand can be named MAIL_SERVER_NAME, the value you specify must be the name (known to the domain name server for your Z/OS host) of your mail server. The host, represented by this name, must be the one capable of receiving and forwarding Simple Mail Transport Protocol (SMTP) mail message for your enterprise. If you include this operand, do not also specify MAIL_SERVER_ADDR.
Default: none
Required: no
MAIL_SERVER_ADDR
Description: Although this operand can be named MAIL_SERVER_ADDR, the value you specify must be the IP address (in dotted decimal notation) of your mail server. The host represented by this name must be the one capable of receiving and forwarding Simple Mail Transport Protocol (SMTP) mail messages for your enterprise. If you include this operand, do not also specify MAIL_SERVER_NAME.
Default: none
Required: no
MAIL_SERVER_PORT
Description: Although this operand can be named MAIL_SERVER_PORT, the value you specify must be the port number that your mail server listens on to receive Simple Mail Transport Protocol (SMTP) mail messages. If you omit this operand, a default value of 25 is used by LMS.
Default: none
Required: no
MAIL_FROM_NAME
Description: Specify the Internet e-mail address (or name) in the form name@institution.type of the individual (or department) designated as the sender of e-mail messages. This name will appear as the FROM: name on all e-mails automatically generated by the License Management System and will receive a copy of all e-mail messages generated.
Default: none
Required: yes
MAIL_TO_SEC_NAME
Description: Specify the e-mail address (or name) that will receive all automatically generated e-mail messages relating to product licensing errors.
This address (or name) can be the name of an individual (or department) within your organization. Even if this name is of an individual (or department) within your organization, you must specify this name in the Internet format, not in a format used locally by your institution.
Default: none
Required: yes
MAIL_TO_ABN_NAME
Description: Specify the e-mail address (or name) that will receive all automatically generated e-mail messages relating to BMC AMI License Management software errors (program ABENDs). This address (or name) can be the name of an individual (or department) within your organization. Even if this name is of an individual (or department) within your organization, you must specify this name in the Internet format, not in a format used locally by your institution.
Default: none
Required: yes
IPV6
Description: This specifies that TCP/IP communication using the specified TCP/IP region should attempt to use the IPv6 protocol.
Values: YES|NO
Default: none
Required: no
License Files
Zero or more license files can be used as input to LMSINIT. Each file is described by a //CWLFnnnn DD statement, where nnnn are any letters or numbers you choose. The remainder of the DD statement describes the name and disposition of one license file.
LMSINIT requires at least one license file unless the Emergency() parameter is specified. In this case only no //CWLFnnnn DD need be supplied.
Message suppression and distribution
This section describes the parameters an administrator must specify to activate the LMS Message Suppression and Distribution feature. The Message Suppression and Distribution (MSD) allows an administrator to tailor the number, content, and destination of warning and error messages generated by the License Management System (LMS). It provides a method whereby an administrator can choose how often certain messages are generated, whether or not these messages should be surrounded by the messages and codes enclosed in asterisks, and specifies where these messages are to be sent. In addition, you can specify your own text to replace the LMS text for messages sent to the BMC AMI products.
Message suppression is performed on a Product/Version or Option/Version basis. That is, each Product/Option/Version will receive the number of messages specified per day (starting when LMSINIT is executed, which resets the date value).
Conditions
Two different conditions are handled by these LMSINIT parameters:
License Warnings | Warning messages are generated when a product is allowed to execute on the current CEC/LPAR, but there is some condition that requires message generation. This condition could be that an emergency password is in effect, or that a particular product or option is within 14 days of expiring. |
License Failures | Failure messages are generated when a product is NOT allowed to execute on the current CEC/LPAR. This condition could be that the product is not licensed on this LPAR, or that the license has expired. |
WARNMSG_CONTENT
Description: VERBOSE specifies that the prologue and epilogue message and codes enclosed in asterisks will be generated. TERSE specifies that only the message(s) specific to the event (i.e. no prologue or epilogue messages) will be generated.
Values: VERBOSE | TERSE
Default: VERBOSE
Required: no
WARNMSG_LIMIT
Description: Specifies how many times per day messages will be generated and distributed for each warning condition. A value of zero indicates that there is no limit: as many times as the warning condition occurs messages will be generated and distributed.
Values: A numeric value between 0 and 9999.
Default: 0
Required: no
WARNDEST
Description: Many possible destinations can be specified for the WARNDEST parameter.
Values: The warning message (as modified by the WARNMSG_CONTENT parameter) is sent to destinations defined as follows:
PRODUCT message is sent to the BMC AMI product. This is the default.
CONSOLE message is sent to a system console (see the DEST, DESC, and CONSNAME operands below).
FAULTMGR message is sent to Abend-AID Fault Analytics.
E-MAIL message is sent via e-mail to the designated recipient.
TSOUSER message is sent to a TSO user (via TPUT). See the MSG_USERID parameter below.
SMF a record is written to the SMF data set regardless of the setting of other LMS SMF parameters.
Default: none
Required: no
WARNTEXT
Description: WARNTEXT statement contains the message text string to be sent to the BMC AMI product destination.
Values: String message to be sent to the BMC AMI product. Only the product will receive this message. The other destinations will receive the messages as defined by LMS. If this operand is specified, then LMS automatically includes PRODUCT in the WARNDEST parameter, even if it was not specified. This text can be from 1 to 56 bytes long and must be enclosed in double quotes ("").
Default: none
Required: no
FAILMSG_CONTENT
Description: VERBOSE specifies that the prologue and epilogue message and codes enclosed in asterisks will be generated. TERSE specifies that only the message(s) specific to the event (i.e. no prologue or epilogue messages) will be generated.
Values: VERBOSE | TERSE
Default: VERBOSE
Required: no
FAILMSG_LIMIT
Description: Specifies how many times per day messages will be generated and distributed for each failure condition. A value of zero indicates that there is no limit: as many times as the failure condition occurs messages will be generated and distributed.
Values: A numeric value between 0 and 9999.
Default: 0
Required: no
FAILDEST
Description: The failure message (as modified by the FAILMSG parameter) is sent to each specified destination. Many possible destinations can be specified for the FAILDEST parameter.
Default: PRODUCT
Values: PRODUCT message is sent to the BMC AMI product. This is the default.
CONSOLE message is sent to a system console (see the DEST, DESC, and CONSNAME operands below).
FAULTMGR message is sent to the BMC Fault Analytics product.
E-MAIL message is sent via e-mail to the designated recipient.
TSOUSER message is sent to a TSO user (via TPUT). See the MSG_USERID parameter below.
SMFA a record is written to the SMF data set regardless of the setting of other LMS SMF parameters.
Required: no
FAILTEXT
Description: The message text that will be received by only the BMC AMI product upon a fail condition.
FAILTEXT(“message_text”)
Values: 1 to 56 byte message string enclosed in double-quotes (“”) to be sent to the BMC AMI product. Only the BMC AMI product will receive this message. The other destinations specified in the FAILDEST statement will receive messages as defined by LMS. If this parameter is specified, then LMS automatically includes PRODUCT as a FAILDEST parameter value.
Default: none
Required: no
ROUTCDE
Description: This parameter applies when FAILDEST=CONSOLE or WARNDEST=CONSOLE is specified. Include the console routing codes to be used for all messages sent to the console. Refer to the IBM publication IBM Programming - Assembler Services Reference for a description of these codes and their meanings. If both ROUTCDE and CONSNAME statements are specified, then the messages will go to all of the consoles specified by both parameters.
Default: 2 and 11
Required: no
DESC
Description: This parameter applies when FAILDEST=(CONSOLE) or WARNDEST=(CONSOLE) is specified. Specify the console descriptor codes to be used for all messages sent to the console. Refer to the IBM publication IBM Programming - Assembler Services Reference for a description of these codes and their meanings. If this parameter is omitted, then no descriptor codes are used.
Default: none
Required: no
CONSNAME
Description: This parameter applies when FAILDEST =CONSOLE or WARNDEST=CONSOLE is specified. Specify the 1- to 8- character name of the console which is to receive messages from LMS. If this name is omitted, then messages are sent to consoles using the routing codes specified for ROUTCDE. If both ROUTCDE and CONSNAME are specified, then the messages will go to all of the consoles specified by both parameters.
Values: 1- to 8-character name of the console
Default: none
Required: no
MSG_USERID
Description: This parameter applies when FAILDEST =TSOUSER or WARNDEST =TSOUSER is specified. Specify the 1- to 8-character SAF user ID to which warning and failure messages are sent. If this parameter is omitted, and TSOUSER is specified, then the user ID under which LMS is running (i.e. the USERID which invoked the BMC AMI product) will receive the messages.
Default: none
Required: no
HISTORY _FILE
Description: By including this operand you are indicating that you want the history file facility enabled. Specifying LOCAL indicates that the history file is to be maintained locally on the LPAR. When this operand is specified, then HISTORY_DSNAME and HISTORY_TRACKS must also be specified. HISTORY_VOLSER, HISTORY_STORCLASS, HISTORY_DATACLASS and HISTORY-MGMTCLASS may optionally be specified as well.
Values: LOCAL
Default: none
Required: no
HISTORY_DSNAME
Description: This parameter is required when HISTORY_FILE=LOCAL is specified, otherwise it not used. Specify the valid 1- to 38-character data set name for the history file. This name must conform to the normal requirements for data set names.
Default: none
Required: no
HISTORY_TRACKS
Description: This parameter is required when HISTORY_FILE=LOCAL is specified, otherwise it not used. Specify the number of tracks to be used as both the primary and secondary extents for the history data set. This value must be numeric within the range of 15 to 9999. We recommend at least 100 tracks be used for this data set.
Default: none
Required: no
HISTORY_VOLSER
Description: This parameter is required when HISTORY_FILE=LOCAL is specified, otherwise it not used. This parameter specifies the 6-character volume serial of the DASD on which the history file will be allocated. LMS automatically defines the history file for you if it does not exist and then uses this data set for subsequent processing. Please check with your SMS administrator to determine if a volume serial number is required or not.
Default: none
Required: no
HISTORY_STORCLASS
HISTORY_DATA_CLASS
HISTORY_MGMTCLASS
Description: This parameter is required when HISTORY_FILE=LOCAL is specified, otherwise it not used. These parameters specify the names your installation has chosen to describe the allocation of this VSAM history data set. If specified, these parameters are used within the IDCAMS DEFINE control statements when the data set is created.
Default: none
Required: no
LPAR_MODE
Description: Specify the mode of sub-capacity licensing you want for this client LMS subsystem. The two choices are SIZE and UTIL.
Values: SIZE is the default and indicates that the capped size of the LPAR in MSUs is to be used as the determining factor in license conformance.
UTIL can be specified to indicate that the current rolling 4-hour average MSU utilization of the LPAR is to be used as the determining factor in license conformance.
- You may specify LPAR_MODE=SIZE or LPAR_MODE=UTIL.
- If you wish, you may spell out utilization by specifying LPAR_MODE=UTIL.
- If this parameter is omitted, the LPAR_MODE=SIZE is used by default.
Default: SIZE
Required: no