Validation Rules

Validation rules contain information for identifying the currently active screen. When a screen appears, Interaction Host Recorder checks the validation rules to determine which screen is loaded. If a person were sitting at the terminal emulation, that person could tell that a screen was valid just by waiting until it finished loading and reading it. When a handler is running the terminal emulation, things become more complicated. The validation rules must specify exactly what determines a valid screen. In many cases you will want to use more than one validation rule, just to make sure that the screen is correct.

When Host Server runs your profile, it will only validate the screen when instructed to do so in a transition command. This means that you will need to configure when screens are validated in your transition commands. If you are recording transition commands automatically, then the validations are inserted for you, but you can also add or remove validations manually in the Transitions Commands window.

Create and edit validation rules in the Screen Definition window

Note: For a new screen (previously undefined in this host profile), you must first name that screen before you can create validation rules.

Interaction Host Recorder evaluates each rule in your list, starting with the top rule in the list. Once it has determined that the first rule is valid, it goes on to the next rule in the list. Interaction Host Recorder will continue to evaluate a rule until it succeeds or times out. (You can set the time out value by right-clicking in the Screen Definition window and choosing Screen Properties from the dialog that appears.

There are six types of validation rules:

• Screen ID
  Each screen has a unique identifier generated mathematically from the number, position, and length of the fields. If you know that the fields will always be in the same place and of the same length, you can use this value. You can use screen ID even if some of the values within fields are going to change. For example, if there is a time stamp located in the top left corner, and that field is always the same length, the screen will keep it's unique id even if the time of day is different.

• Screen Type
  The number of unprotected fields on the screen. If you know that a screen has finished loading when an input field has appeared, use the screen type as one of your validation rules. It is possible that several different screens will have the same number of input fields, and thus have the same screen type. In most cases, screen type should not be used as the only validation rule. This validation rule should only be used when a screen will always have the same number of unprotect6ed fields.

• Match Text
  This versatile validation rule allows you to look for a specific text string anywhere on the screen, anywhere starting at a specific row, anywhere starting in a specific column, or starting in a specific row/column coordinate. You should use this validation rule when you know that each screen has a unique identifier somewhere on the screen. Many mainframe application designers realize that their screens will be evaluated electronically, so they include a unique number in a corner of the screen.

• Wait
  Forces a pause while Interaction Host Recorder validates the screen. Wait should only be used when no other validation rules can be used to validate the screen.
  
  Caution: Be careful that you don't set the wait time for longer than the validation timeout or the validation will always fail.

• Cursor Position
  Looks for the cursor in a specific row, column, or row/column coordinate. For example, you might use cursor position when you know that the cursor will be in row twenty-five when the screen has finished loading. You should not use cursor position if the cursor is not always in the same location after a screen loads.

• Is Ready to Send (RTS)
  Checks to see if the host has sent an RTS signal indicating that the screen is ready to accept user input. You might use this as a final validation rule after other rules have been checked. For example, if the host sends between fifteen and twenty RTS signals before the screen finishes loading, then you might Match Text for a textual value at the bottom of the screen and then validate the RTS signal. This way you know that the screen has finished loading and is ready for input.