Device-dependent maps

Because the position, default attributes, and default contents of map fields appear only in the physical map and not in the symbolic map, you can use a single program to build maps that contain the same variable information but different constant information in different arrangements on the screen.

Device-dependent maps are very convenient if the program you are writing must support multiple devices with different characteristics. You do this by defining multiple maps with the same names but different attributes and layout, each with a different suffix.

Suppose, for example, that some of the clerks using the quick update transaction use 3270 Model 2s ( as we have assumed until now), and the rest use a special-purpose terminal that has only 3 rows and 40 columns. The format we designed for the big screen will not do for the small one, but the information will fit if we rearrange it:

Figure 1. Quick update for the small screen

 QUP Quick Account Update:
					Current charge okay; enter next
					Acct: _______ Charge: $ _______

We need the following map definition:

Figure 2. Map definition

QUPSET DFHMSD
TYPE=MAP,STORAGE=AUTO,MODE=INOUT,LANG=COBOL,SUFFIX=9
QUPMAP DFHMDI SIZE=(3,40),LINE=1,COLUMN=1,CTRL=FREEKB
DFHMDF POS=(1,1),LENGTH=24,ATTRB=(ASKIP,BRT), X
INITIAL='QUP Quick Account Update'
MSG DFHMDF LENGTH=39,POS=(2,1),ATTRB=(ASKIP,NORM)
DFHMDF POS=(3,1),LENGTH=5,ATTRB=(ASKIP,NORM), X
INITIAL='Acct:'
ACCTNO DFHMDF POS=(3,11),LENGTH=6,ATTRB=(UNPROT,NUM,IC)
DFHMDF POS=(3,18),LENGTH=1,ATTRB=(ASKIP),INITIAL=' '
DFHMDF POS=(3,20),LENGTH=7,ATTRB=(ASKIP,NORM),INITIAL='Charge:'
CHG DFHMDF POS=(3,29),LENGTH=7,ATTRB=(UNPROT,NORM),PICIN='$$$$0.00'
DFHMDF POS=(3,37),LENGTH=1,ATTRB=(ASKIP),INITIAL=' '
DFHMSD TYPE=FINAL

The symbolic map set produced by assembling this version of the map is identical to the one shown in An input-output example , because the fields with names have the same names and same lengths, and they appear in the same order in the map definition. (They do not need to appear in the same order on the screen, incidentally; you can rearrange them, provided you keep the definitions of named fields in the same order in all maps.) You only need one copy of the symbolic map and you can use the same code to build the map.

CICS® will select the physical map to use from the value coded in the ALTSUFFIX option of the TYPETERM resource definition for the terminal from which the transaction is being run. You also need to specify SCRNSZE(ALTERNATE) in the transaction PROFILE resource definition. For information about the TYPETERM and PROFILE resource definition, see RDO resources.

You might use this technique to distinguish among standard terminals used for special purposes. For example, if an application were used by both English and French speakers, you could create two sets of physical maps, one with the constants in French and the other in English. You would assign each a suffix, and specify the English suffix as the ALTSUFFIX value in the definitions of the English terminals and the French suffix for French terminals. Transactions using the map would point to a PROFILE that specified alternate screen size. Then when you sent the map, BMS would pick the version with the suffix that matched the terminal (that is, in the appropriate language).

Another way to provide device dependent maps is to allow BMS to generate a suffix based on the terminal type, and select the physical map to use to match the terminal in the current execution when you issue SEND MAP or RECEIVE MAP.