Differences between classic Rules and Rules Management Rules

Aside from the most obvious difference (windows mode vs. full-screen mode), one of the primary goals was to increase flexibility. There are a number of differences when editing Rules with the windows mode editor. There are fewer dialogs and you can scroll forwards and backwards within the dialogs. You can also access Rules Management Rules from MainView Explorer (MVE). The following sections outline some of the other differences.

• • DELAY() keyword
  • Change reason
  • Radio buttons
  • Checkboxes (YES or NO)
  • Checkboxes (one of many choices)
  • Larger data entry fields
  • Journal option
  • Issue WTO or Journal Message
  • Mixed case entry
  • BiiZ and BEIM differences
  • Prompter panels
  • Collect Diagnostics
  • Send an Email from a Rules Management Rule action
  • Send SNMP traps from a Rules Management Rule action
  • Chained Rule Groups
  • Issue USS commands from a Rules Management Rule action
  • Issuing ZOAU commands from a Rules Management Rule action
  • Enhanced Selection Criteria option for EOS-initiated Rules (PTF BQO3939 applied)

DELAY() keyword

The DELAY() keyword that delays a Rule from scheduling an EXEC or the issuing a command is enhanced to support a SHARED variable as the delay value. This allows you to dynamically set the amount of delay for all commands or EXECs that use the SHARED variable.

For example, now you can specify the variable &MYVAR to delay scheduling an EXEC.

Change reason

In Rules Management, you can specify the reason for the change to the Rules and retain the reason as part of the Rule's change history. A record of up to the last ten (10) changes is kept for review using a hyperlink.

For example, the following example text shows a change reason added at the bottom of the dialog.

Radio buttons

The availability of radio buttons is only possible when you are using the MainView Explorer user interface. Required fields where you must select a value from a list of values in Rules Management use radio buttons. Radio buttons provide an easy way to choose an option without having to deselect the value that was previously selected. Selecting a new option automatically deselects any previous option.

Checkboxes (YES or NO)

Virtually all of the Rules options that required you to specify YES or NO have been converted to checkboxes. For example, instead of Display at Dest: ___where you specify YES or NO (or leave it blank to get the default), the Rules Management editor uses a checkbox that looks like this: Display at Dest: _ Yes.

Normally, a checkbox that is left unchecked is the same as leaving a field blank in the full-screen editor. The default value is implied as being the opposite of the supplied prompt. That is, if the default is NO, then the checkbox will be checked to get the YES option.

Checkboxes (one of many choices)

Rules fields that contain a one of many values are now shown as checkboxes. The values are all listed and it is simpler to select the option that you want. You can see an example of this change with the Rule action specification of Command. In classic Rules, you had to either know the value the command type or use Help to find out. Now you can see two rows of checkboxes which identify all the valid command types that you can select from.

Larger data entry fields

The Rules Management windows mode editor provides enough space for all fields to be entered in their entirety without the use of special additional dialogs. For example, on the classic Rules Actions dialog (A1), the EXEC/Parms field is limited to 126 characters due to screen size restriction. The Rules Management windows mode editor provides the full 255-character field for data entry.

Journal option

Many Rule event types support the Journal option. This option echoes the event's message to the BBI-SS journal when selected. Many event types also offer the ability to reword the event's message or command. For these event types, the Journal option has a third variation. The third option (besides YES and NO) is REW. When REW was specified, the reworded message/command is used for the text sent to the BBI-SS Journal by the option. In the Rules Management editor, a separate checkbox labeled Reworded is displayed with the Journal option when it is available for the event type.

Issue WTO or Journal Message

The classic Rules action for Issue WTO (or Journal or Both) has been split. In the classic full-screen editor, you had to choose what to issue (WTO, JRN, or BOTH) and enter the text to be issued. In the Rules Management windows mode editor, these fields are now split apart. You no longer a need to specify what to issue separately from the text. If you want to iissue a WTO, you can put the text in the Issue WTO text field.

This is also true for the Issue Journal Message text field. Splitting the field means that you can send different texts to WTO and the Journal in the same Rule.

Mixed case entry

In the classic full-screen Rules editor, the use of mixed-case values was severely restricted and required special coding allowances. Mixed-case, however, is much more common now than it was in the past.

The Rules Management windows mode editor has expanded the number of fields that support mixed-case data entry. These fields are documented in the online help. The primary fields affected by this change on the Actions dialog (A1) are the EXEC/Parms, Reword, Issue WTO, and Issue Journal Message fields. Additionally, on the Alert Action dialog (AA), the Alert Text and Alert Follow-Up EXEC/Parms also support mixed-case values. The Final Action field on the AA dialog supports mixed-case only when the EXEC option is selected. Otherwise, it is uppercase only.

BiiZ and BEIM differences

Several changes have been made to the Rules BEIM Actions dialog (BZ). Some of these were to improve usability and others where to allow the user full use of data fields that were previously restricted in size or number in classic Rules.

In classic Rules the BEIM Event Action Name/Value Pairs, these pairs were restricted both in number and in length. The classic Rules panel allowed you to enter a fixed number of eight pairs with the name length set to a maximum of 33 characters, and the slot value length is restricted to 38 characters.

These restrictions were implemented due to space considerations on the panel but for some customers, these limitations were too restrictive. In the Rules Management windows mode editor, the slots now support a variable number of slots. The slot name still has a maximum of 33 characters but you can enter a slot value up to 255 bytes. The total number of slots is limited only by the aggregate length of all the slot pairs. The maximum length is 600 bytes (including the 4 bytes of overhead for each name/value pair).

In classic Rules, the BEIM Alert Action Name/Value pairs were also restricted to a fixed number of eight pairs, the maximum name length is set to 33 characters, and the slot value length is restricted to 38 characters. In the Rules Management windows mode editor, the number of pairs is still eight and each slot name is still limited to 33 characters. However, each slot value has now been expanded to a maximum of 255 bytes per slot value.

Prompter panels

The classic full-screen Rules editor includes dialogs known as prompter panels which are displayed when you enter a question mark in a field, followed by a blank, and press Enter. The prompter panel includes help information that you can select (such as a command type) or the panel could help you create optional prefix keywords. These panels are useful for some command types that support a large variety of prefix keywords.

The Rules Management windows-mode editor still supports a prompter system but it is now required to use them when editing any of the Rule fields that provided a prompter panel in classic Rules. In addition, the Rules Management editor uses the term modifier instead of prefix. The term modifier more accurately reflects what the keywords do to the command or EXEC. They modify (or otherwise alter) when and how the command is issued.

There are primarily two reasons for this change: better usability and improved accuracy. With the Rules Management editor, you can see the modifier keywords and know which one(s) are required. This change makes it easier to create Rules as well as makes you aware of modifier keywords that you might not have known before.

Collect Diagnostics

The Rules Management application supports a Collect Diagnostics function so a Rule can gather information when an event occurs. You can specify additional requirements such as collect data from up to five views, as well as request a console dump of address and data spaces. 

You can specify that data collected from the views is written to a BMC AMI Ops Automation array (also called view data arrays), the body of an Email, a sequential data set, or any combination of the three. The FAILLIST view allows you to browse the contents of the view data arrays. From the FAILLIST view, you can also take additional actions such as delete or modify expiration attributes assigned to each view data array.

To specify this action, you must specify an active Host Server, and ensure that the EXEC QCDINIT (shipped in hi-level.BBPROC) is entered in the SYSPROC concatenation of the BMC AMI OpsA PAS JCL.  For more information about the Collect Diagnostics action, view the following quick courses:

Using the Rule Action 

Getting Dumps

Using View Parameters

Limiting View Data

Exporting Data Arrays

Managing Data Arrays

MainView AO Diag

Send an Email from a Rules Management Rule action

Rules Management Rules support an action where they can send an email directly instead of using a REXX EXEC. For more information, see Rules-actions-that-are-specific-to-the-Rules-Management-application or view the quick course Send an Email from a Rules Management Rule.

Send SNMP traps from a Rules Management Rule action

Rules Management Rules support an action where they can send send SNMP traps instead of using a REXX EXEC. The SNMP traps are sent by way of the BMC AMI OpsA SNMP sub-agent to the IBM SNMP Agent. For more information, see Rules-actions-that-are-specific-to-the-Rules-Management-application or view the quick course Send SNMP traps from a Rules Management Rule.

Chained Rule Groups

Rules Management Rules support chained Rule groups (CRGs) that provide advanced Rule chaining for complex automation without requiring REXX EXECs. For more information, see Creating-a-Chained-Rule-Group or view the quick course Rules Management chained Rule groups.

Issue USS commands from a Rules Management Rule action

Rules Management Rules can issue an Action Specification Command: Type USS.  In this field, you can specify a USS program or a script.  Select Command: Type USS to issue programs or scripts from the BBI-SS address space. This is a simple way for Rules to issue a REST API call by invoking the open source curl program or by running a USS script.

The following example shows how to enter a USS command to print the curl version to the MVS syslog:

The following example shows how you can issue both USS commands and execute a USS script by stacking the calls in the Edit field: 

USS commands are case-sensitive and you must enter them using the correct case for the command to work properly. Built-in functions are supported. Any modifier that you specify is applied to all commands that are specified.                        

You can issue the BBI command .D A to look for active solutions in the BBI-SS PAS.

For more information about sending REST API calls from a Rules Management Rule, see Using-REST-API-with-BMC-AMI-Ops-Automation.

Issuing ZOAU commands from a Rules Management Rule action

BMC AMI OpsA users can access the IBM Z Open Automation Utilities (ZOAU). You can issue ZOAU commands either from EXECs scheduled from any Rule, or in a USS script scheduled from the Rules Management Rule Action Specification field Command: Type USS. The processing flow below shows how a Rule directly runs a script that calls ZOAU commands and how a Rule schedules an EXEC that runs a script:

For more information about ZOAU commands and coding requirements, including Python requirements, see the IBM ZOAU web site.

The following three examples show prerequisites you need to set before Bash, Java  and Python scripts and programs can issue ZOAU commands. For more information about ZOAU commands, see to the IBM documentation Z Open Automation Utilities. 

• You must set the following file redirection and environmental variables before issuing ZOAU commands in your Bash script: 

• You must set the following file redirection and environmental variables before invoking your Java program that calls the ZOAU API: 

You can use the chtag command to change the file tag.

You must set the following file redirection and environmental variables before invoking your Python program:

Enhanced Selection Criteria option for EOS-initiated Rules (PTF BQO3939 applied)

You can create Rules for the End-of-Step (EOS) event, which occurs whenever an address space changes steps. For Rules Management EOS initiated Rules, you can specify a less than (<) or greater than (>) value on the Step CC Selection Criteria field. Use the less than or greater than symbols to specify a value higher or lower than a specific condition code. 

For example, you can specify Step CC ....: >4, which means the Rule will fire when the condition code for the EOS event is greater than 4.