Using predefined screen formats for alphanumeric applications

GDDM V3R2 Base Application Programming Guide

Using predefined screen formats for alphanumeric applications

GDDM V3R2 Base Application Programming Guide
SC33-0867-01

If you create a display that includes procedural alphanumeric data, you must format it. In other words, you must define the positions and attributes of all the alphanumeric fields on the screen or printer page. Mapping is an alternative technique for doing this. Essentially, it means you define the format of a display before its execution, instead of doing it dynamically in your application program.

The predefined format is called a map. It is most convenient to create maps interactively. GDDM provides a product for this, called Interactive Map Definition (GDDM-IMD). Using GDDM-IMD, you can indicate on a screen where all the alphanumeric fields in a display are to start and end, and you can enter codes to define their attributes, such as their color and whether they are protected.

Information about how to use GDDM-IMD is provided in two places: within GDDM-IMD itself and in the GDDM Interactive Map Definition book.

In addition to the position of a field and its attributes, you can define its content to GDDM-IMD and arrange that neither the application program nor the terminal operator can alter it. Such fields are called constant data fields. Fields that can be altered are called variable data fields.

GDDM-IMD generates a coded form of the maps you create, to be used by GDDM when your program sends data to, and receives data from, the terminal. On output, GDDM builds the display you require by merging variable data supplied by your program with the formatting information and constant data contained in the map. On input, GDDM separates the variable data from the rest of the input, and passes it to your program; the variable data contains any input typed in by the operator.

You can find an example of a simple mapping program in Figure 81 in topic 15.2 and its associated display in Figure 83 in topic 15.2.1.

The means by which the variable data is passed to and from the application by GDDM is a program variable called an application data structure (ADS). There is an example at A in Figure 81. You specify to GDDM-IMD which fields are to appear in the ADS, and thus define them to be variable data fields. The ADS is the only means by which the program can alter fields, so those not represented in it are constant data fields.

The ADS in the example contains only data without any details of its presentation to the end user. It demonstrates the major advantage of GDDM mapping; you concentrate on data processing when you write your program, and leave the presentation entirely to GDDM.

The facilities described in "Basic procedural alphanumerics" and "Advanced procedural alphanumerics" are known as procedural alphanumerics, to distinguish them from the mapping facilities. As with procedural alphanumerics, GDDM mapping uses hardware cells and fields. Mapping is therefore restricted to display units and printers of the IBM 3270 family, and to system printers. In a dual-screen configuration of the IBM 3270-PC/GX workstation, mapped data appears on the alphanumerics screen. On the 5080 and 6090 Graphics Systems, it appears on the 3270 screen.

GDDM-IMD provides default values for many of the items that it asks you to specify. The maps used in the examples in this guide were created using the GDDM-IMD defaults, except where stated otherwise.

Full GDDM mapping support is limited to programs written in PL/I, COBOL, and System/370 Assembler, because only these languages enable application data structures to be used. FORTRAN programmers, however, can use maps. They can transmit the constant data, and are not precluded from supplying variable data by means other than GDDM-IMD created structures.

If you write applications in C/370 or REXX you cannot use the map generated by GDDM-IMD directly. You must first create the map for another language and then convert the ADS into a form than can be passed to a C/370 or REXX program. To help REXX programmers with this task, GDDM provides a utility program called ERXMSVAR. The ERXMSVAR utility converts an ADS generated by GDDM-IMD to data suitable for a REXX exec.

Note: Do not specify a '.' as part of the "prefix" parameter passed to ERXMSVAR. This could cause the resulting variables to be treated as REXX stem variables and their values could be substituted and changed. Another separator character, such as "_", is safer.

GDDM also provides a subcommand for REXX programs to transfer values from variables into the ADS and vice versa. See the descriptions of the ERXMSVAR exec and the GXSET subcommand in the GDDM Base Application Programming Reference book.

The ERXORDER sample exec shows how to use the the GXSET MSADS and GXSET MSVARS subcommands to move mapping data, created using the ERXMSVAR utility, between the application and GDDM-REXX. ERXORDER is described in "REXX sample programs" in topic A.7.

For an example of how to code an application data structure for use with a C/370 program, see "ADS conversion for mapping applications written in C/370" in topic 15.2.3.

Notices | Terms of use | Support | Contact z/OS