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. This is 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:
QUP Quick Account Update: Current charge okay; enter next Acct: _______ Charge: $ _______
We need the following 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. See CICS Resource Definition Guide for information about the TYPETERM and PROFILE resource definitions.
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.
The BMS feature that does this is called "device dependent support" (DDS). DDS is an installation option that works as follows.
When you assemble your map sets, you specify the type of terminal the maps are for in the TERM option. This causes the assembler to store the physical map set under the MAPSET name suffixed by the character for that type of terminal5. When you issue SEND MAP or RECEIVE MAP with DDS active, BMS adds a 1-character suffix to the name you supply in the MAPSET option. It chooses the suffix based on the definition of your terminal, and thus loads the physical map that corresponds to the terminal for any given execution.
BMS defines the suffixes used for the common terminal types. A 3270 Model 2 with a screen size of 24 rows and 80 columns is assigned the letter ‘M,’ for example. The type is determined from the TYPETERM definition if it is one of the standard types shown in Table 39.
Code | Terminal or logical unit |
---|---|
A | CRLP (card reader input, line printer output) or TCAM
terminal.
Note: ![]() In CICS TS 3.1, local TCAM
terminals are not supported. The only TCAM terminals supported are remote
terminals connected to a pre-CICS TS 3.1 terminal-owning region by the DCB
(not ACB) interface of TCAM. ![]() |
B | Magnetic tape |
C | Sequential disk |
D | TWX Model 33/35 |
E | 1050 |
F | 2740-1, 2740-2 (without buffer receive) |
G | 2741 |
H | 2740-2 (with buffer receive) |
I | 2770 |
J | 2780 |
K | 3780 |
L | 3270-1 displays (40-character width) |
M | 3270-2 displays (80-character width), LU type 2s |
N | 3270-1 printers |
O | 3270-2 printers, LU type 3s |
P | All interactive LUs, 3767/3770 Interpreter LU, 3790 full function LU, SCS printer LU |
Q | 2980 Models 1 and 2 |
R | 2980 Model 4 |
U | 3600 (3601) LU |
V | 3650 Host Conversational (3653) LU |
W | 3650 Interpreter LU |
X | 3650 Host Conversational (3270) LU |
Y | 3770 Batch LU, 3770 and 3790 batch data interchange LUs, LU type 4s |
blank | 3270-2 (default if TERM omitted) |
An installation can also define additional terminal types, such as the miniature screen described above. The system programmer does this by assigning an identifier to the terminal type and specifying it in the ALTSUFFIX option of the TYPETERM definition for the terminals. When you create a map for such a terminal, you specify this identifier in the SUFFIX option, instead of using the TERM option. Transactions using the map must also point to a PROFILE that specifies alternate screen size, so that ALTSUFFIX is used.
With DDS, the rules BMS uses for selecting a physical map are:
Without DDS, BMS always looks first (and only) for an unsuffixed map.
Device-dependent support is an installation option for BMS, set by the system programmer in the system initialization table. Be sure that it is included in your system before taking advantage of it; you should know whether it is present, even if you are supporting only one device type.
With DDS in the system, there is an efficiency advantage in creating suffixed map sets, even if you are supporting only one device type, because you prevent BMS from attempting to load a map set that does not exist before defaulting to the universal one (the blank suffix).
Without DDS, on the other hand, it is unnecessary to suffix your maps, because BMS looks for the universal suffix (a blank) and fails to locate suffixed maps.
Because of the overall design of BMS, and device-dependent support in particular, you generally do not need to know much about your terminal to format for it. However, if you need to know the characteristics of your principal facility, you can use the ASSIGN and INQUIRE commands. You can tell, for example, whether your terminal supports a particular extended attribute, what national language is in use, screen size and so on. This type of information applies whether you are using BMS or terminal control to communicate with your terminal. You need it more often for terminal control, and so we describe the options that apply in that chapter, in Finding out about your terminal.
There are also ASSIGN options specific to BMS, but you need them most often when you use the ACCUM option, and so we describe them later, in ASSIGN options for cumulative processing.