An input-output example

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:

Figure 110. Normal "quick update" response
  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:

Figure 111. "Quick update" error response
  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:

Figure 112. Map definition for input-output map
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:

Figure 113 shows the symbolic map set that results from this INOUT map definition.

Figure 113. Symbolic map for "quick update"
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 symbolic input map

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:

L
the length of the input in the map field.
F
the flag byte, which indicates whether the operator erased the field and whether the cursor was left there.
I
the input data itself.

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 ]]