Differences between classic Rules and Rules Management Rules

Aside from the most obvious difference (windows mode vs. fullscreen mode), one of the primary goals was to modernize and increase flexibility. To this end, there are a number of differences when editing Rules with the windows mode editor. One of the first is that there are fewer dialogs and the dialogs are scrollable forward and backward. And, because the editor works in windows mode, it is now available directly in 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 the flexibility 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, Rules allow you to specify a change reason where you can document the reason for the change 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 use of radio buttons is only noticeable when using the MainView Explorer user interface. Required fields that force you to choose one 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 whatever option was previously selected. Selecting the 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. This makes it obvious what the options are without needing to memorize any acronyms or abbreviations, as well as making it easy to select the desired option. You can see an example of this change with the Rule action of Command. In classic Rules, you had to either know what value to use for the command type or use Help to find out. Now you can see two rows of checkboxes. These checkboxes 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 helper 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 supplies 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 new Rules editor, you will now see a separate checkbox labeled Reworded associated with the Journal option when it is available for that Rule event type.

Issue WTO or Journal Message

The classic Rules action for Issue WTO (or Journal or Both) has been split. In the classic fullscreen 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 offers a series of dialogs that were collectively called the prompter panels. The prompter panel is invoked when you enter a question mark into a field followed by a blank and pressing enter. The resulting panel would provide help that you can select such as a command type or the panel would assist in the creation of any optional prefix keywords. This is especially useful for some command types that supported 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. No longer will you be tempted to guess at what the modifier keywords are and which one(s) are required. No longer will you be tempted to stack EXECs when stacking is not allowed. This change makes the creation of Rules easier as well as making you aware of modifier keywords that you might not have known before.