|
|
|
Every generated skeleton corresponds to an individual screen within a CA 2E function. In a Web Option client job, each time a screen is displayed by the CA 2E application program that is running, Web Option retrieves the skeleton that was generated for that screen, merges variable data from the screen with the skeleton, and sends the resulting HTML page to the client browser.
For this process to work, there must be a link that associates the CA 2E screen and the skeleton that was generated for the screen. This association is done using a Screen Identifier (SID):
For display file DDS generated from CA 2E, the SID is a 10-byte string of characters inserted into the DDS and output as a hidden (non-displayed) field .
For all other types of display file DDS, the SID is a reference on a cross-reference file that refers to one or more uniquely identifying pieces of text on the screen. This virtual SID must be created by using the YWRKSCRXRF command.
Screen identification is controlled by two files held in Y2WEBVENG:
This file holds the data that links a particular screen to its SID. A record is added to this file when a CA 2E screen that contains a SID is generated and also when a screen is manually identified. If Web Option encounters a screen that does not contain a real SID at runtime, it accesses the file to see if the screen has been manually identified.
This file holds data that links a particular SID to a generated skeleton. A record is added to this file when a skeleton is generated for a display file using the YGENMLS command. Web Option accesses this file at runtime, when it has retrieved a SID (either directly from the screen or by checking for a manually identified screen), to retrieve the name of the skeleton with which the screen data is merged.
This section contains the following topics:
Screen Identifiers in CA 2E Generated DDS
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |