HATS Studio - Timing issues

 

+
Search Tips   |   Advanced Search

 

 

Pause after an action

There are two settings that let you add a pause after actions during runtime:

• Pause Between Actions on the Macro tab
• Set Pause Time on the General tab of the Screens tab

 

Speed of processing actions

Because the macro runtime executes actions much more quickly than a human user does, unforeseen problems can occur during macro playback that cause an action not to perform as expected, because of a dependency on a previous action.

One example is a keystroke that causes the application screen to change. If a subsequent action expects the application screen to have already changed, but in fact the application screen is still in the process of being updated, then the subsequent action can fail.

Timing-dependent errors between actions can occur in many other situations, if the macro runtime performs each action immediately after the preceding action.

 

Pause Between Actions (Macro tab)

The Pause Between Actions field on the Macro tab causes the macro runtime to wait a specified number of milliseconds after every action in the entire macro. That is, after the macro runtime performs an action, the macro runtime checks the Pause Between Actions setting to see if it is enabled. If so, then macro runtime waits the specified number of milliseconds, then goes on to perform the next action.

By default this checkbox is enabled and the timeout value is set to 300 milliseconds. Therefore the macro runtime will wait for 300 millliseconds after every action that it performs.

Notice that this wait is added after every action of every macro screen. Therefore this one setting allows you avoid this type of problem without having to change each macro screen that might have a problem.

 

Set Pause Time (General tab of the Screens tab)

If you want a longer or shorter pause time between actions for a particular macro screen, or if you have only a few macro screens in which the wait interval between actions is important, then you can use the Set Pause Time setting on the General tab of the Screens tab.

By default this checkbox is disabled.

If you enable this setting, then the macro runtime waits for the specified number of milliseconds after each action in this particular macro screen.

For example, if for ScreenA you select the Set Pause Time checkbox and set the value to 500 milliseconds, then the macro runtime waits 500 milliseconds after each action in ScreenA.

When the macro runtime processes a macro screen with Set Pause Time enabled, it ignores the setting of the Pause Between Actions option on the macro tab, and uses only the value in the Set Pause Time setting.

 

Adding a pause after a particular action

If you need a longer pause after one particular action in a macro screen, you can add a Pause action after the action. The wait that you specify in the Pause action is in addition to any wait that occurs because of a Pause Between Actions or a Set Pause Time.

 

Screen completion

 

Recognizing the next macro screen too soon

Suppose that you have a macro screen, ScreenB, with the following bug: the macro runtime starts processing the actions in ScreenB before the host has completely finished displaying the new application screen. Although this timing peculiarity might not pose a problem for you in most situations, suppose that in this instance the first action in ScreenB is an Extract action that causes the macro runtime to read data from rows 15 and 16 of the application screen. Unfortunately the macro runtime performs this action before the host has had time to write all the new data into rows 15-16.

Analyzing this problem, you verify that:

• The session is a 3270 Display session using the default connectivity, TN3270.
• The following sequence of actions occurs:

  1. In processing the previous macro screen, the macro runtime performs an Input action that causes an enter key to be sent to the host.
  2. The host receives the enter key and sends the first block of commands and data for the new application screen.
  3. The client receives the first block and processes it, thereby updating some parts but not all of the host application screen. In particular, rows 15 and 16 of the application screen have not yet been updated.
  4. Meanwhile the macro runtime has started trying to recognize a valid next macro screen that matches the new application screen.
  5. As a result of the changes in the application screen from the first block of commands and data, the macro runtime recognizes macro ScreenB as the next macro screen to be processed.
  6. The macro runtime performs the first action element in ScreenB, which is an Extract action that reads data from rows 15 and 16 of the application screen.
  7. The client receives a second block of commands and data from the host and processes it, thereby updating other parts of the application screen, including rows 15 and 16.

In short, as a result of this timing problem the macro runtime has read rows 15 and 16 of the new application screen before the host could finish update them.

 

The ordinary TN3270 protocol

The reason for this problem is that the unenhanced TN3270 protocol does not include a way for a host to inform a client that the host application screen is complete. (TN3270 implements a screen-oriented protocol, 3270 Data Stream, over a character-oriented connection, Telnet). Therefore, the host cannot send several blocks of data to the client and then say, "OK, the application screen is now complete - you can let the user enter data now." Instead, each block arrives without any indication about whether it is the last block for this application screen. From the client's point of view, something like the following events occur:

1. A block of commands and data arrives. The client sets the input inhibit indicator, processes the block, and displays the new data on the specified parts of the host terminal. The client then clears the input inhibit indicator and waits.
2. 30 milliseconds pass.
3. Another block of commands and data arrives. The client processes the block as in step 1 above. This block causes a different part of the screen to be updated. The client waits.
4. 50 milliseconds pass.

This process continues until the host has completely displayed a new host application data screen. The client still waits, not knowing that the host application screen is complete. (For more information, see How the macro runtime processes a macro screen).

This process does not present problems for a human operator, for various reasons that are not important here.

However, this process does present problems for the macro runtime during screen recognition. Recall that during screen recognition the macro runtime tries to match the application screen to one of the valid next macro screens every time the screen is updated and every time an OIA event occurs (see Re-doing the evaluation). Therefore the macro runtime might find a match before the screen is completely updated. For example, a String descriptor might state that recognition occurs if row 3 of the application screen contains the characters "ISPF Primary Option Menu". When the host has updated row 3 to contain these characters, then the macro runtime determines that a match has occurred, regardless of whether the host has finished updating the remainder of the application screen.

 

Solutions

There are three approaches to solving this problem:

• Add more descriptors to the description.
• Insert a delay after the Input action that sends an enter key (see step 1 in Recognizing the next macro screen too soon).
• Use the contention-resolution feature of TN3270E.

The following subsections describe these solutions.

Add more descriptors

This approach works sometimes but can be awkward and unreliable. You add enough descriptors to the description part of ScreenB so that the macro runtime will not recognize the ScreenB until the critical portion of the application screen has been updated.

Insert a delay after the input action

Inserting a delay is the best solution if the session is an ordinary TN3270 session or if the session is a TN3270E session without contention-resolution. That is, after the Input action (in ScreenA in our example) that causes the host to send a new application screen, insert a pause of several hundred milliseconds or longer. This delay allows enough time for the host to update the application screen before the macro runtime starts processing the actions in the next macro screen (ScreenB).

In this scenario there are several ways to insert a pause after the Input action:

• Increase the Pause Between Actions delay. However, the Pause Between Actions delay is inserted after every action in every macro screen of the macro.
• Increase the Set Pause Time for ScreenA. This method is a good one. You are increasing the pause time after every action in ScreenA, so that only ScreenA is affected.
• Add a Pause action to ScreenA immediately after the Input action. This method is also good. You are inserting a pause exactly where it is needed.
• Add a Pause action as the first action of ScreenB. You might prefer this method in certain scenarios. However, using this method, if there are several macro screens that can occur after ScreenA (such as ScreenB, ScreenC, ScreenD), and if the screen completion problem occurs for each of these following macro screens, then to insert a Pause as the first action for each of these following macro screens. It is easier to use the method in the previous bullet and insert a Pause Action in one macro screen, ScreenA.

If your macro has to run both on ordinary TN3270 sessions and also on TN3270E sessions with contention-resolution enabled, the XML macro language has several attributes that can help you. See Attributes that deal with screen completion.

Use the contention-resolution feature of TN3270E

TN3270E (Enhanced) is an enhanced form of the TN3270 protocol that allows users to specify an LU or LU pool to which the session will connect and that also supports the Network Virtual Terminal (NVT) protocol for connecting to servers in ASCII mode (for example, in order to log on to a firewall).

Contention-resolution mode is an optional feature of TN3270E, supported by some but not all TN3270E servers, that solves the client's problem of not knowing when the host has finished updating the application screen. If the client is running a TN3270E session and is connected to a server that supports contention-resolution, then the macro runtime does not recognize a new macro screen until the host has finished updating the application screen.

In Host On-Demand you can set a 3270 Display session to use TN3270E rather than TN3270 by clicking the appropriate radio button on the Connection configuration window of the 3270 Display session configuration panel.

This panel does not contain an option for setting contention-resolution support, because Host On-Demand detects contention-resolution mode automatically, if the host supports it, when the TN3270E session is started.

 

Attributes that deal with screen completion

Host On-Demand has three element attributes that address problems that the macro developer encounters when trying to support a single version of a macro to run on both the following environments:

• A non-contention-resolution environment (the macro is being run by clients connected to a TN3270 server or to a TN3270E server without contention resolution; consequently some macro screens might require a Pause action to allow time for the host to update the application screen).
• A content-resolution enviroment (the macro is being run by clients connected to a TN3270E server with contention resolution; consequently no macro screen requires a Pause action to allow time for for the host to update the application screen).

You will have to add these attributes using the source view.

ignorepauseforenhancedtn=true/false

The ignorepauseforenhancedtn parameter of the <HAScript> element, when set to true, causes the macro runtime to skip Pause actions (<pause> elements) during macro playback if the session is running in a contention-resolution environment. Use this attribute if you developed a macro to run in a non-contention-resolution environment (you inserted Pause actions) and you now want the macro to also run in a contention-resolution environment without unnecessary delays (you want the Pause actions to be ignored).

With this attribute set to true, the macro runtime processes Pause actions (waits the specified number of milliseconds) in a non-contention-resolution environment but ignores Pause actions in a contention-resolution environment.

Notice, however, that setting this attribute to true causes the macro runtime to skip all Pause actions (<pause> elements) in the macro, not just the pauses that have been inserted in order to time for the application screen to be updated. The next subsection addresses this secondary problem.

ignorepauseoverrideforenhancedtn=true/false

The ignorepauseoverrideforenhancedtn parameter of the <pause> element, when set to true in a particular <pause> element, causes the macro runtime to process that <pause> element (wait for the specified number of milliseconds) even if the ignorepauseforenhancedtn attribute is set to true in the <HAScript> element.

Set this attribute to true in a <pause> element if you want the <pause> element always to be performed, not skipped, even in a contention-resolution environment with the ignorepauseforenhancedtn attribute set to true in the <HAScript> element.

delayifnotenhancedtn=(milliseconds)

The delayifnotenhancedtn parameter of the <HAScript> element, when set to a non-zero value, causes the macro runtime to automatically pause the specified number of milliseconds whenever the macro runtime receives a notification that the OIA (Operator Information Area) has changed.

Use this attribute if you developed a macro in a contention-resolution environment (you did not need to insert Pause actions) but you now want the macro to run also in a non-contention-resolution environment (some macro screens might need a Pause action to allow time for the application screen to be completed).

With this attribute set to true, then when the macro is run in a non-contention-resolution environment the macro runtime inserts a pause for the specified number of milliseconds each time it receives a notification that the OIA has changed. For example, if you specify a pause of 200 milliseconds then the macro runtime waits for 200 milliseconds every time the OIA changes.

The cumlative effect of the macro runtime pausing briefly after each notification of a change to the OIA is that the application screen is completed before the macro runtime begins processing the actions of the new macro screen. The macro runtime inserts these extra pauses only when it detects that the session is running in a non-contention-resolution environment.

A limitation of this attribute is that the macro runtime adds these extra pauses during every screen, not just during screens in which screen update is a problem. However, the additional time spent waiting is small. And more importantly, this attribute lets you quickly adapt the macro to a non-contention resolution environment, without having to test individual screens and insert a pause action in each screen with a screen update problem.

 

Home