Identifying Application Screens › Screen Identifiers in CA 2E Generated DDS

Screen Identifiers in CA 2E Generated DDS

This section discusses using a *SCREEN ID in the header/footer of a CA 2E display file to identify screens. If you do not want (or are unable) to use a header/footer containing the *SCREEN ID, follow the instructions in the section Manually Identifying a Screen in this chapter.

A Define screen format (DFNSCRFMT) function named *STD SCREEN HEADINGS(MLS) is included in the *Standard Header/Footer file. This function is identical to the *STD SCREEN HEADINGS(CUA) function, except that it contains the *SCREEN ID field at row 2, column 2. The inclusion of the *SCREEN ID field in this header causes a SID to be generated into the DDS source of any function that uses this header/footer function.

The *STD SCREEN HEADINGS(MLS) header part of the header/footer appears as follows:

*PROGRAM   *PGMMOD                                    DD/MM/YY HH:MM:SS
*SCREEN ID              *STD SCREEN HEADINGS (MLS)

You can change and regenerate a function that currently uses the default *STD SCREEN HEADINGS(CUA) header/footer to use the *STD SCREEN HEADINGS(MLS) header/footer; the green-screen looks exactly the same and the positions of the fields on the screen do not change.

If you want to use the *STD SCREEN HEADINGS(MLS) header/footer function as the default for all your 2E functions, you need to set the new shipped MLS Header/Footer, *STD SCREEN HEADINGS(MLS), to be the default:

1. F into the *Standard header/footer file from the Edit Database Relations panel.
2. Z into *STD SCREEN HEADINGS(MLS) and press F7=Options.
3. Set the Use as default for functions flag to 'Y'.

If you only want certain functions to contain the *SCREEN ID in the device design, then do not make the above change and simply select the *STD SCREEN HEADINGS(MLS) for those functions before generation.

When CA 2E generates the display file and the header/footer contains the *SCREEN ID field, the SID is generated into the DDS as a non-display field, so that it is not visible to users. However, the HTML generator can see the SID in the DDS source and uses it to determine the name of the HTML skeleton to generate. It is also visible to the Web Option server, which uses it at runtime to determine the HTML skeleton with which to merge data.

The CA 2E display file DDS generator inserts the SID into the DDS source in the format C2Ennnnnnn (where nnnnnnn is a unique number assigned to that screen). Each screen in a multi-screen function has a different SID. For example, an EDTRCD3 function has four screens, Key Screen, Detail Screen 1, Detail Screen 2 and Detail Screen 3, each of which has a different SID. This results in 4 different skeletons being created when the YGENMLS command is run over this function.

For example, the DDS for a display file can include the following:

      * *SCREEN ID                                        
     A                                            2  2'C2E0001025'
     A                                                 DSPATR(ND)

If you do not use the *STD SCREEN HEADINGS(CUA) header/footer, but have defined your own header/footer, you can add the *SCREEN ID field to that header/footer. The *SCREEN ID field can be included anywhere in the header section.

Once your functions have been regenerated to include the *SCREEN ID field, you are ready to generate HTML skeletons for your screens.