Before we explain the details of the input structure, let us re-examine the "quick check" example. Suppose that it is against our policy to let a customer charge up to the limit over and over again between the nightly runs when new charges are posted to the accounts. We want a new transaction that augments "quick check" processing by keeping a running total for the day.
In addition, we want to use the same screen for both input and output, so that there is only one screen entry per customer. In the new transaction, "quick update," the clerk enters both the account number and the charge at the same time. The normal response is:
QUP Quick Account Update Current charge okay; enter next Account: _______ Charge: $ _______
When we reject a transaction, we leave the input information on the screen, so that the clerk can see what was entered along with the description of the problem:
QUP Quick Account Update Charge exceeds maximum; do not approve Account: 482554 Charge: $ 1000.00
(Here again, we are oversimplifying to keep our maps short for ease of explanation.)
The map definition we need for this exercise is:
QUPSET DFHMSD TYPE=MAP,STORAGE=AUTO,MODE=INOUT,LANG=COBOL,TERM=3270-2
QUPMAP DFHMDI SIZE=(24,80),LINE=1,COLUMN=1,CTRL=FREEKB
DFHMDF POS=(1,1),LENGTH=3,ATTRB=(ASKIP,BRT),INITIAL='QUP'
DFHMDF POS=(1,26),LENGTH=20,ATTRB=(ASKIP,NORM), X
INITIAL='Quick Account Update'
MSG DFHMDF LENGTH=40,POS=(3,1),ATTRB=(ASKIP,NORM)
DFHMDF POS=(5,1),LENGTH=8,ATTRB=(ASKIP,NORM), X
INITIAL='Account:'
ACCTNO DFHMDF POS=(5,14),LENGTH=6,ATTRB=(UNPROT,NUM,IC)
DFHMDF POS=(5,21),LENGTH=1,ATTRB=(ASKIP),INITIAL=' '
DFHMDF POS=(6,1),LENGTH=7,ATTRB=(ASKIP,NORM),INITIAL='Charge:'
CHG DFHMDF POS=(6,13),ATTRB=(UNPROT,NORM),PICIN='$$$$0.00'
DFHMDF POS=(6,21),LENGTH=1,ATTRB=(ASKIP),INITIAL=' '
DFHMSD TYPE=FINAL
You can see that the map field definitions for this input-output map are very similar to those for the output-only "quick check" map, if we allow for changes to the content of the screen. The differences to note are:
If you define the stopper field as "autoskip", the cursor jumps to the next unprotected field after the operator has filled the preceding input field. This is convenient if most of the input fields are of fixed length, because the operator does not have to advance the cursor to get from field to field.
If you define the stopper field as "protected," but not "autoskip," the keyboard locks if the operator attempts to key beyond the end of the field. This choice may be preferable if most of the input fields are of variable length, where one usually has to use the cursor advance key anyway, because it alerts the operator to the overflow immediately. Whichever you choose, you should use the same choice throughout the application if possible, so that the operator sees a consistent interface.
Figure 113 shows the symbolic map set that results from this INOUT map definition.
01 QUPMAPI.
02 FILLER PIC X(12).
02 FILLER PICTURE X(2).
02 MSGL COMP PIC S9(4).
02 MSGF PICTURE X.
02 FILLER REDEFINES MSGF.
03 MSGA PICTURE X.
02 MSGI PIC X(40).
02 ACCTNOL COMP PIC S9(4).
02 ACCTNOF PICTURE X.
02 FILLER REDEFINES ACCTNOF.
03 ACCTNOA PICTURE X.
02 ACCTNOI PIC X(6).
02 CHGL COMP PIC S9(4).
02 CHGF PICTURE X.
02 FILLER REDEFINES CHGF.
03 CHGA PICTURE X.
02 CHGI PIC X(7) PICIN '$,$$0.00'.
01 QUPMAPO REDEFINES QUPMAPI.
02 FILLER PIC X(12).
02 FILLER PICTURE X(3).
02 MSGO PIC X(40).
02 FILLER PICTURE X(3).
02 ACCTNO PICTURE X(6).
02 FILLER PICTURE X(3).
02 CHGO PIC X.
The second part of this structure, starting at QUPMAPO, is the symbolic output map--the structure required to send data back to the screen. Apart from the fields we redefined, it looks almost the same as the one you would have expected if we had specified MODE=OUT instead of MODE=INOUT. See Figure 102 for a comparison. The main difference is that the field attributes (A) subfield appears to be missing, but we explain this in a moment.
The first part of the structure, under the label QUPMAPI, is new. This is the symbolic input map--the structure required for reading data from a screen formatted with map QUPMAP. For each named field in the map, it contains three subfields. As in the symbolic output map, each subfield has the same name as the map field, suffixed by a letter indicating its purpose. The suffixes and subfields related to input are:
The input and output structures are defined so that they overlay one another field by field. That is, the input (I) subfield for a given map field always occupies the same storage as the corresponding output (O) subfield. Similarly, the input flag (F) subfield overlays the output attributes (A) subfield. (For implementation reasons, the order of the subfield definitions varies somewhat among languages. In COBOL, the definition of the A subfield moves to the input structure in an INOUT map, but it still applies to output, just as it does in an output-only map. In assembler, the input and output subfield definitions are interleaved for each map field.)
BMS uses dummy fields to leave space in one part of the structure for subfields that do not occur in the other part. For example, there is always a 2-byte filler in the output map to correspond to the length (L) subfield in the input map, even in output-only maps. If there are output subfields for extended attributes, such as color or highlighting, BMS generates dummy fields in the input map to match them. You can see examples of these fields (FILLERs in COBOL) in both Figure 102 and Figure 113.
The correspondence of fields in the input and output map structures is very convenient for processes in which you use a map for input and then write back in the same format, as you do in data entry transactions or when you get erroneous input and have to request a correction from the operator.
[[ Contents Previous Page | Next Page Index ]]