General information about recording loops

A recorded loop simplifies and generalizes the processing of a repeated sequence of application screens in a flow.

You are not required to record a repeated sequence of application screens as a loop but it is frequently useful to do so. The advantages of a recorded loop are:
  • Efficiency: Instead of processing every application screen that occurs in a repeated sequence a loop processes only the application screens that occur within one iteration.
  • Generality: The loop works properly whether the repeating sequence of application screen recurs only once or multiple times.
You record a loop by navigating through a terminal application and using the loop controls (see Controls for recording a loop).
Note: You can use Extract actions and Insert actions within a recorded loop. Also, with Extract actions you can select whether to store the extracted text into the same instance of a variable or into a separate instance of the variable for each iteration of the loop (see Creating Extract actions and Insert actions during flow recording).

After a loop is recorded you can customize it if necessary to meet your requirements (see the customizing of the recorded loop in the first tutorial, Step 3.3: Add logic to the invoked flow).

A recorded loop is implemented using the following types of artifacts:
  • The recorded flow contains the While node for the loop and several related nodes.
  • The flow invoked by the While node is populated with Invoke screen operations nodes to handle the application screens that you visit during the loop recording and other nodes.
  • A loop variable is added to the variable message.
See Implementation of a recorded loop.

Recording a multipage list as a loop

A very common scenario in which a recorded loop is useful is a multipage list of items, like the multipage list displayed in the CICS® example catalog application that is recorded in the first tutorial (see C. Record the flow information). Typically each page in such a list has the same layout and similar wording in the header and footer. But the central area of the page where the items in the list are displayed is different for each page: the first page might display items 0001 through 0015, the second page items 0015 through 0019, and so on through the pages until all the items in the list are displayed. The number of pages required to display the entire list varies, depending on the number of items in the list at the time.

Figure 1 is a representation of this type of scenario. Items R through X are a series of application screens that a user encounters in navigating through a hypothetical terminal application (this same figure is used in Repeating sequence of one application screen):
Figure 1. A sequence of application screens with a single-screen repeated sequence U1, U2, U3, U4
R,S,T,(U1),(U2),(U3),(U4),V, W, X

Screens U1 through U4 are the application screens that the user encounters when paging all the way through the multipage list from start to finish. These four application screens have similarities in format and in the wording of the headers and footers, while the central area of each screen displays the sequential items in the list. The number of pages required to display all the items in the list can be greater or less than four, depending on the number of items in the list.

Because of the similarities in appearance of application screens U1 through U4, a single screen description (U) can be used to recognize all four application screens. Consequently these application screens can be recorded as four iterations of a single loop, with each iteration consisting of one application screen.

Moreover, the recorded loop generalizes the information in the application screens so that the loop can handle any number of iterations.

Recording a repeated sequence of multiple screens

Less commonly a repeated sequence can consist of more than one application screen (see Repeating sequence of multiple application screens).