Custom automation recommendations

Custom automation are EXECs, scripts, and BMC AMI Ops Automation Rules that automation specialists and administrators write and maintain. Although you can't always avoid using custom automation, you should eliminate or reduce it as much as possible. In most cases, TOM has functions or capabilities that eliminate the need for custom automation.

Automation variables

TOM provides various classes of automation variables that contain information about objects' attributes and statuses. You can implement these automation variables as BMC AMI Ops Automation shared pool variables.

Important

To reduce overhead, avoid or minimize using automation variables.

LIST-function

Using-Rules-with-BMC-AMI-Ops-Automation

Using-advanced-automation-with-BMC-AMI-Ops-Automation

Implementing-Rules-Management

If you must use automation variables, we recommend enabling only the ones you need. To enable or disable the Automation Variable class, specify VARIABLES_xxx=YES|NO in BBPARM member MAMINIxx. Each object that requires automation variables must have a unique short name attribute value. If you need automation variables only on the system in which the object resides, you can further reduce overhead and improve performance by assigning them to the local system. To do so, specify VARIABLE_LOCAL=YES in BBPARM member MAMINIxx. Specifying VARIABLE_LOCAL=NO maintains the variables on each BMC AMI OpsA in the TOMPLEX.

You can also use automation variables when operators are not trained to use the TOM START and STOP commands for STM objects and instead use the MVS START and STOP commands.

To issue the MVS START and STOP commands by using automation variables, follow these guidelines:

Because the TOM START and STOP commands require objects names (instead of cataloged-procedure, STC, or job names), you must first translate the name of the MVS START and STOP commands to the object name by specifying VARIABLES_GENERAL=YES in BBPARM member MAMINIxx.
Define the STC name as the short-name attribute for each STM object or use the &@SHORTNAME to make TOM to create a general class of automation variables for every object that has a short name.
Add CMD Rules to BMC AMI OpsA for the MVS START and STOP commands to issue the TOM START and STOP commands by using the object name. The object name is the OBJNAME value of the prefix.shortName.OBJNAME Automation Variable. BMC AMI OpsA obtains the shortName value (STC name) from Rule variable WORD2.

TOMEXEC APIs

When using TOMEXEC FUNC(LIST) and FUNC(GET) EXECs to process every object in a Definition Base, you can improve performance greatly by using the list token. When you request a FUNC(LIST) with the REXX variable stem.LIST.KEEP=YES, a token returns and the allocated storage for the objects and their attributes are retained for use by subsequent FUNC(GET) requests. This prevents Registry access for the FUNC(GET) of each object. After TOM has processed all the objects, you can release the list storage by issuing the TOMEXEC FUNC(LIST) with REXX variables stem.LIST.KEEP=NO and stem.LIST.TOKEN=token. To limit resource utilization, you can have only four concurrent lists per TOM. If the EXEC does not release the list within 30 minutes of obtaining it, TOM automatically releases it.

If you are using multiple TOMs (TOMPLEX) on your system or in the playpen, specify TOMPLEX(tomplex-name) on all TOMEXEC API requests to direct the request to the proper TOM.

EXECs

If possible, avoid using EXECs. Each EXEC requires an execution thread in BMC AMI OpsA and an automation specialist must keep maintaining them. Instead, consider using the various type commands (VPUT, TOM, WTO, LOG, and JRNL) provided by TOM for the following commands:

Pre-start
Post-start
Retry-start
Pre-stop
Post-stop
Stop
Recovery

OpsA variables

OpsA provides shared variables that you can use for storing data that you can pass between Rules and EXECs. Shared variables last in the OpsA PAS for the life of an IPL. If you need variables to last longer, use profile variables. OpsA automation can also access the symbols for the local system. For more information, see Using-advanced-automation-with-BMC-AMI-Ops-Automation and SHARED-variables-usage-and-pools.

OpsA Rules

OpsA provides Rules that can perform a variety of actions that are available in EXCEs. You can simultaneously run an unlimited number of Rules with no overhead.

The Rules Management application provides many features and capabilities, including the ability to define and use Chained Rule Groups (CRGs). You can use CRGs to chain together a set of Rules that act as a single unit to automate an event. For more information, see Using-Rules-with-BMC-AMI-Ops-Automation. If you use CRGs, you can use the IF-THEN-ELSE logic to decide when actions should occur when you select a Rule. For more information, see Creating-a-Chained-Rule-Group and Implementing-Rules-Management.