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.
- The session is a 3270 Display session using the default connectivity, TN3270.
- The following sequence of actions occurs:
- In processing the previous macro screen, the macro runtime performs an Input action that causes an enter key to be sent to the host.
- The host receives the enter key and sends the first block of commands and data for the new application screen.
- 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.
- Meanwhile the macro runtime has started trying to recognize a valid next macro screen that matches the new application screen.
- 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.
- 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.
- 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.