Differences between Rules Management Rules and classic Rules

• • Issue multi-line WTO messages
  • DELAY() keyword
  • Better handling of different versions
  • Change reason
  • Extended free-form user notes
  • Radio buttons
  • Checkboxes (YES or NO)
  • Checkboxes (one of many choices)
  • Larger data entry fields
  • Journal option
  • Issue WTO or Journal Message
  • Mixed-case values 
  • 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 

Issue multi-line WTO messages

Any Rules Management Rule can issue a multi-line message (MLWTO) as an action. 

From the Actions menu, select Issue MLWTO:

Use the Send Multiline WTO Message dialog to enter the MLWTO text:

Each LINE can have up to 71 characters. You can also use variables and enter route codes, descriptor codes, and a console name. Built-in functions are supported. Delay parameters are optional.

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.

Better handling of different versions

BMC AMI OpsA improves handling Rules Management Rules deployed to target PASs that are not running at the same product version or maintenance level. The following enhancements help you identify Rules added (or modified) at a later version of Rules Management and deployed to a PAS that does not support all of the Rule's options and actions:

• Implementation of an internal identifier, Continuous Delivery Level (CDL), in each Rule and in the PAS.  
   
• Support of the MIGRULES parameter in BBPARM member AAOPRMxx. When you specify MIGRULES=YES, the ALLRULES view displays the Rules that failed to load with a status of INV.   This allows you to easily identify which Rules failed to load due to a conflict in CDL levels. 

The following views or dialogs are modified to include information about the PAS or Rule CDL level. You should check for any automation that could be impacted by the additional information provided in the view.

• ASYS 
• RSETR   
• RULESR 
• RPOOL 
• RULES 
• RSETRMBR 
• Rules Management Rules Editor – Detail Control dialog

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 Chg Rsn field added at the bottom of the dialog:

Extended free-form user notes

You can enter up to an additional 10 extended free-form user notes (per Rule) in addition to Rule's 512-character User Notes field. Each extended free-form user note supports an up to 64-character subject line and 1024 characters for the body of the note. Each note automatically tags the time and date that it was added or edited and the user ID of the person who added or updated the note.    

From the Rule Processor Detail Control dialog, you can insert, edit, or remove a note. You can also rearrange the Extended User Notes table using the Top and Bottom commands. The following shows the Rules Processor Detail Control panel with the Extended User Notes fields:

 The following shows an example of an extended free-form user note entry view: 

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 values 

In the classic full-screen Rules editor, using mixed-case values is very restricted and requires special coding allowances.

The Rules Management application supports mixed-case values in many more places. The following lists the fields in the Rules Management dialogs that support mixed-case values: 

• Actions dialog (A1) box: EXEC/Parms, Reword, Issue WTO, and Issue Journal Message
• Alert Action dialog (AA) box: Alert Text and Alert Follow-Up EXEC/Parms 
• Alert Action dialog (AA) box: the Final Action field supports mixed-case only when the EXEC option is selected. Otherwise, it is uppercase only
• Set Variables (AV) dialog box: Advanced Set Variables and Set Variables fields

You can find additional information in the online Help for the dialogs.

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. Email and SNMP Rule actions

Send SNMP traps from a Rules Management Rule action