Browse Prior Art Database

Legacy Host Application Component Extraction Formatting Rules

IP.com Disclosure Number: IPCOM000013762D
Original Publication Date: 2000-Apr-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 80K

Publishing Venue

IBM

Abstract

A method and apparatus allowing host screen component extraction developers to add formatting rules to screen component extraction events from legacy host system datastream screens (3270, 5250, VT, etc.). A previously submitted disclosure describes the method for formatting a host screen into usable XML based components (lists, input, descriptions, etc.). The current disclosure builds on this idea by allowing the host screen navigation application developer to split the component extraction into rule events and component events. This is especially useful for a host application that has screens that contain exactly the same formatting throughout the application's system (e.g. function keys across the bottom of the screen and menu items across the top). It makes sense to reduce the amount of processing by just sending one event to the developer's application that contains the rules for formatting the general portions of the screen and sending subsequent events that contain the dynamic portion of the screen. This reduces processing time and data transfer amounts because we're not formatting and sending the entire contents of each and every screen. Let us use the callup application as an example. After you input a person's name to search, you will get the result screen from the host. The list of action codes on the top and the list of function keys at the bottom do not change from screen to screen. They can be sent in an event as "rules" for the screens in Callup. The middle part, which contains the variable screen contents, would be sent with every new screen, with the rules applied to them to make the screen complete. Note: there could be many other rules than just the dynamic/static screen area example. One possible implementation of this would be to add functionality to IBM Host On-Demand's Macro bean. At run time, the Macro engine will first determine if rules are applied to a screen. If there are rules, the Macro bean will fire a rule event if one has not been fired. The dynamic screen data can either be piggy-backed on the rule event or fired in a separate event. Thereafter, the Macro bean only fires the dynamic components for each screen containing the rule. These rules can either be coded inline in the macro or there can be link points to the actual storage of the rules in a database.

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

Legacy Host Application Component Extraction Formatting Rules

  A method and apparatus allowing host screen component extraction developers to add formatting rules to screen component extraction events from legacy host system datastream screens (3270, 5250, VT, etc.). A previously submitted disclosure describes the method for formatting a host screen into usable XML based components (lists, input, descriptions, etc.). The current disclosure builds on this idea by allowing the host screen navigation application developer to split the component extraction into rule events and component events. This is especially useful for a host application that has screens that contain exactly the same formatting throughout the application's system (e.g. function keys across the bottom of the screen and menu items across the top).

    It makes sense to reduce the amount of processing by just sending one event to the developer's application that contains the rules for formatting the general portions of the screen and sending subsequent events that contain the dynamic portion of the screen. This reduces processing time and data transfer amounts because we're not formatting and sending the entire contents of each and every screen.

    Let us use the callup application as an example. After you input a person's name to search, you will get the result screen from the host. The list of action codes on the top and the list of function keys at the bottom do not change from screen to screen. They can be sent in an event as "rules" for the screens in Callup. The middle part, which contains the variable screen contents, would be sent with every new screen, with the rules applied to them to make the screen complete. Note: there could be many other rules than just the dynamic/static screen area example.

    One possible implementation of this would be to add functionality to IBM Host On-Demand's Macro bean. At run time, the Macro engine will first determine if rules are applied to a screen. If there are rules, the Macro bean will fire a rule event if one has not been fired. The dynamic screen data can either be piggy-backed on the rule event or fired in a separate event. Thereafter, the Macro bean only fires the dynamic components for each screen containing the rule. These rules can either be coded inline in the macro or there can be link points to the actual storage of the rules in a database.

Benefits/Claims

    Helps the application avoid extracting static compon...