The interaction of physical map definition options, SEND MAP options, program data and merge options is sufficiently complex that a summary of the rules for determining what appears on the screen after a SEND MAP is in order.
The contents of the screen (buffer) are determined by:
We discuss the possibilities in that order.
The first thing that happens on a SEND MAP command is that the entire screen (buffer) is cleared to nulls if the ERASE option is present, regardless of the size or origin of your map. On terminals that have the alternate screen size feature, the screen size is set as well, as explained in 3270 write commands. The screen is in unformatted state, with no fields defined and no display data. If ERASEAUP is present, all of the unprotected fields on the screen are erased, but the field structure and attributes of all fields and the contents of protected fields are unchanged.
ERASE and ERASEAUP are honored before your SEND MAP data is loaded into the buffer. If neither of these options appears on the SEND MAP, the screen buffer starts out as it was left after the previous write operation, modified by whatever the operator did. In general, the positions of the fields (that is, of the attributes bytes) and their attributes are unchanged, but the data content of unprotected fields may be different. Furthermore, if the operator used the CLEAR key, the whole buffer is cleared to nulls and the screen is in unformatted state, just as if you had included the ERASE option.
Secondly, BMS changes only those positions in the buffer within the confines of your map. Outside that area, the contents of the buffer are unchanged, although it is possible for areas outside your map to change in appearance, as explained in Outside the map.
Within the map area, what is sent depends on whether the DATAONLY option is present. In the usual case, where it is not present, BMS sends every component (field attributes, extended attributes, display data) of every field in your map. This creates a field at the position specified in the POS operand and overlays the number of bytes specified in the LENGTH field from POS. Buffer positions between the end of the display data and the next attributes byte (POS value) are left unchanged. (There may or may not be fields (attributes bytes) in these intervening spaces if you did not ERASE after the last write operation that used a different map.)
The values for these field elements come from the program, the map or defaults, as explained in the next section.
If DATAONLY is present, on the other hand, BMS sends only those fields, and only those components for them, that the program provides. Other screen data is unchanged.
The values that determine screen contents may come from four sources:
BMS considers each component of each map field separately, and takes the value from the program, provided:
If any of these conditions is not met, the next step depends on whether DATAONLY is present. With DATAONLY, BMS stops the process here and sends only the data it got from the program. BMS does this in such a way that components not changed by program are not changed on the screen. In particular, extended attributes values are not changed unless you specify a new value or ask for the hardware default. (A value of X'FF' requests the hardware default for all extended attributes except background transparency, for which you specify X'F0' to get the hardware default.)
Without DATAONLY, if one of the conditions above is not met, BMS takes the data from the map, as follows:
We have assumed, so far, that your map is the same size as your screen or printer page. It need not be. Your application may use only a part of the screen area, or you may want to build your output incrementally, or both.
BMS logical messages allow you to build a screen from several maps, sending it with a single terminal write. You use the ACCUM option to do this, which we cover in BMS logical messages. Even without using ACCUM, you can build a screen from several maps if the terminal is a 3270-like device with a buffer. You do this with multiple SEND MAP commands written to different areas of the screen (buffer), not erasing after the first command. Each SEND MAP causes output and may produce a momentary "blink" at a display device. For this reason, and to eliminate the path length of extra I/O, you may prefer to use logical messages for such composite screens.
Outside the map just sent, the contents of the buffer are unchanged, except for the effects of ERASE and ERASEAUP cited earlier. In general, this means that the corresponding areas of the screen are unchanged. However, a screen position outside the map may get its attributes from a field within the map. This occurs if you do not define a field (using a different map) beyond the boundary of the map and before the position in question. If you change the attributes of the field inside your map governing this position outside, the appearance of the position may change, even though the contents do not.
One use of the buffer overlay technique we just described is the creation of screens containing a mixture of BMS and Graphical Data Display Manager (GDDM®) output. You generally write the BMS output first, followed by the GDDM. You can leave space in the BMS map for the GDDM output, or you can create a "graphic hole" in any display by writing a map with no fields in it to the position where you want the hole. Such a map is called a "null map," and its size (height and width) correspond to the size of the hole.
If you use GDDM to combine graphics with BMS output, you need to include a GDDM PSRSRV call to prevent GDDM from corrupting programmed symbol sets that BMS may be using.
[[ Contents Previous Page | Next Page Index ]]