An input-output example

This example shows you the map definition for a simple data entry program called "quick update".

Before we explain the details of the input structure, let us reexamine the “quick check” example in A BMS output 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 1. 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 about the screen, so that the clerk can see what was entered along with the description of the problem:

Figure 2. “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 3. 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 like those for the output-only “quick check” map, if we allow for changes to the content of the screen. The differences to note are:

The MODE option in the DFHMSD map set definition is INOUT, indicating that the maps in this map set are used for both input and output. INOUT causes BMS to generate a symbolic structure for input as well as for output for every map in the map set. If this had been an input-only map, we would have said MODE=IN, and BMS would have generated only the input structures.
We put names on the fields from which we want input (ACCTNO and CHG) as well as those to which we send output (MSG). As in an output-only map, we avoid naming constant fields to save space in the symbolic map.
The input fields, ACCTNO and CHG, are unprotected (UNPROT), to allow the operator to key data into them.
IC (insert cursor) is specified for ACCTNO. It positions the cursor at the start of the account number field when the map is first displayed, ready for the first item that the operator has to enter. (You can override this placement when you send the map; IC just provides the default position.)
Just after the ACCTNO field, there is a constant field consisting of a single blank, and a similar one after the CHG field. These are called “stopper” fields. Normally, they are placed after each input field that is not followed immediately by some other field. They prevent the operator from keying data beyond the space you provided, into an unused area of the screen.
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.
The CHG field has the option PICIN. PICIN produces an edit mask in the symbolic map, useful for COBOL and PL/I, and implies the field length. See DFHMDF for details on using PICIN.

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

Figure 4. 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 1 for a comparison. The main difference is that the field attributes (A) subfield appears to be missing, but we explain this in a moment.