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

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 textfield. 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 changes

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 action 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. 

Data collected from the views can be written to either an MainView AutoOPERATOR array (also called view data arrays), the body of an Email, or both.  You can use the new view FAILLIST 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 MainView Host Server, and ensure that the EXEC QCDINIT (shipped in hi-level.BBPROC) is entered in the SYSPROC concatenation of the MainView AutoOPERATOR PAS JCL.   For more information, see Rules actions that are specific to the Rules Management application. You can also learn more about the Collect Diagnostics action in the following quick courses:

Using the Rule Action 

Getting Dumps

Using View Parameters

Limiting View Data

Exporting Data Arrays

Managing Data Arrays

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 MainView AutoOPERATOR 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.