Browse Prior Art Database

Loop Prevention in Host Access Products with Screen Recognition and Automatic Screen Navigation Capabilities

IP.com Disclosure Number: IPCOM000014845D
Original Publication Date: 2001-Feb-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 3 page(s) / 48K

Publishing Venue

IBM

Abstract

A programming technique is disclosed which can be used to prevent looping problems in products that provide access to host systems, specifically those which provide the capability to recognize host screens and automatically navigate to subsequent screens. This invention solves the two types of looping problems that can be found in these type of products: 1) Automatic screen navigation path loop When a particular host screen is recognized, it can be automatically bypassed by having some predefined command or key entered. If the next screen presented by the host is also recognized, it too can be automatically bypassed, and so on and so on. In some cases, it is possible that a screen will be encountered in this automatic navigation path that was already part of this automatic navigation sequence, which will result in the same set of screens being navigated through again (and again, and again, infinitely ...)

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

  Loop Prevention in Host Access Products with Screen Recognition and Automatic Screen Navigation Capabilities

   A programming technique is disclosed which can be used to prevent looping problems in products that provide access to host systems, specifically those which provide the capability to recognize host screens and automatically navigate to subsequent screens.

This invention solves the two types of looping problems that can be found in these type of products:

1) Automatic screen navigation path loop

When a particular host screen is recognized, it can be automatically bypassed by having some predefined command or key entered. If the next screen presented by the host is also recognized, it too can be automatically bypassed, and so on and so on. In some cases, it is possible that a screen will be encountered in this automatic navigation path that was already part of this automatic navigation sequence, which will result in the same set of screens being navigated through again (and again, and again, infinitely ...)

An example of this would be where Screen1 (e.g., VM Running screen ) automatically navigates to Screen2 (e.g. Phone lookup) which navigates to Screen3 (e.g., dept listing), which navigates back to Screen1 (VM Running). Screen1 would again automatically navigate to Screen 2, which would go back to Screen 3, which would go back to Screen 1 and so on.

2) Manual navigation loop back to the same/last screen

As in the previous problem, when a particular host screen is recognized, it can be automatically bypassed by having some predefined command or key entered. If the next screen presented by the host is also recognized, it too can be automatically bypassed, and so on and so on. Eventually, the navigation completes, and a screen will be encountered that has no navigation to the next screen, and is displayed to the user for consumption and action. If the user action is such that will cause one of the previously bypassed screens to be encountered, the automatic navigation will again follow the same steps as before, returning the user to the screen he/she just acted on. In some cases, this can leave the user with no way to exit from a particular screen, as all actions will result in one of the previous screens which will again automatically navigate back to the current one.

An example of this would be where Screen1 (e.g. ISPF primary) automatically navigates to Screen2 (e.g., Browse selection), which navigates to Screen3 (e.g browse of a particular file), and Screen3 is presented to the user and not automatically navigated from. If the user takes an action (e.g., PF3), it returns him/her to Screen2, which again automatically navigates back to Screen3, giving him no way to ever get off of Screen3.

1

Page 2 of 3

In order to overcome this limitation, the program first needs to keep a hist...