The first time we need to send a map to a terminal occurs in program ACCT00, where we display the menu screen. The command we need is:________________________________________________________________________ | | | EXEC CICS SEND MAP('ACCTMNU') MAPSET('ACCTSET') MAPONLY | | ERASE FREEKB END-EXEC. | | | |________________________________________________________________________| This is a very simple situation. Because we don't have any variable data to put in the map, we can use the MAPONLY option, and we don't have to worry about preparing variable data for merging with the physical map.
If we were sending some data to the screen with the map, we could not use MAPONLY, and CICS would expect the data to be used for filling in the map to be in a structure whose name is the map name (as specified in the MAP option) suffixed with the letter O. So, when we issue the command: ________________________________________________________________________ | | | EXEC CICS SEND MAP('ACCTMNU') MAPSET('ACCTSET') | | END-EXEC. | | | |________________________________________________________________________| CICS expects the data for the map to be in a structure within the program (of exactly the sort generated by the DSECT assembly) named ACCTMNUO. This structure is usually in your WORKING-STORAGE Section, but it might be in a LINKAGE area instead. (There's an option on the SEND MAP command that lets you specify a data structure other than the one assumed by CICS. We won't cover it here, but you can find guidance on using it in the CICS/ESA Application Programming Guide. under "Sending Data to a Display.") Let's look at the more common situation in which we're merging program data into the map. In program ACCT01, we're supposed to build a detail display map for one record and send it to the screen. Since the contents of the screen vary somewhat with the type of request, and we're using the same screen for all types, this will entail the following:
1. Putting the appropriate title on the map (add, modify, or whatever it happens to be). 2. Moving the data from the file record to the symbolic map (except for adds). 3. Adjusting the attribute bytes. The input fields must be protected in a display or delete operation; the "verify" field must be unprotected for deletes, and the titles at the bottom of the screen must be made nondisplay for adds. 4. Putting the appropriate user instructions (about what to do next) into the message area. 5. Putting the cursor in the right place. Figure 43 shows how the necessary code might look. ________________________________________________________________________ | | | Col Col | | 7 12 | | BUILD-MAP. | | IF REQC = 'X' MOVE 'DELETION' TO TITLEDO, | | MOVE -1 TO VFYDL, MOVE DFHBMUNP TO VFYDA, | | MOVE 'ENTER "Y" TO CONFIRM OR "CLEAR" TO CANCEL' | | TO MSGDO, | | ELSE MOVE -1 TO SNAMEDL. | | IF REQC = 'A' MOVE 'NEW RECORD' TO TITLEDO, | | MOVE DFHPROTN TO STATTLDA, LIMTTLDA, HISTTLDA, | | MOVE ACCTC TO ACCTDI, | | MOVE 'FILL IN AND PRESS "ENTER," OR "CLEAR" TO CANCEL' | | TO MSGDO, | | GO TO SEND-DETAIL. | | IF REQC = 'M' MOVE 'RECORD CHANGE' TO TITLEDO, | | MOVE 'MAKE CHANGES AND "ENTER" OR "CLEAR" TO CANCEL' | | TO MSGDO, | | ELSE IF REQC = 'D', | | MOVE 'PRESS "CLEAR" OR "ENTER" WHEN FINISHED' | | TO MSGDO. | | MOVE CORRESPONDING ACCTREC TO ACCTDTLO. | | MOVE CORRESPONDING PAY-HIST (1) TO PAY-LINE. | | MOVE PAY-LINE TO HIST1DO. | | MOVE CORRESPONDING PAY-HIST (2) TO PAY-LINE. | | MOVE PAY-LINE TO HIST2DO. | | MOVE CORRESPONDING PAY-HIST (3) TO PAY-LINE. | | MOVE PAY-LINE TO HIST3DO. | | IF REQC = 'M' GO TO SEND-DETAIL, | | ELSE IF REQC = 'P' GO TO PRINT-PROC. | | MOVE DFHBMASK TO | | SNAMEDA, FNAMEDA, MIDA, TTLDA, TELDA, ADDR1DA, | | ADDR2DA, ADDR3DA, AUTH1DA, AUTH2DA, AUTH3DA, | | AUTH4DA, CARDSDA, IMODA, IDAYDA, IYRDA, RSNDA, | | CCODEDA, APPRDA, SCODE1DA, SCODE2DA, SCODE3DA. | | * SEND THE RECORD DETAIL MAP TO THE TERMINAL. | | SEND-DETAIL. | | EXEC CICS SEND MAP('ACCTDTL') MAPSET('ACCTSET') ERASE FREEKB | | CURSOR END-EXEC. | | | |________________________________________________________________________| Figure 43. Building the detail display map
Here are some explanatory notes.
REQC (request code) was moved to a working-storage field earlier in the program. It holds the user's "request code."
What is happening in this code is as follows:
o If the user request is to delete a record (IF REQC = X):
1. The map title is changed from its default to DELETION.
2. The cursor is placed under the "verify" field (MOVE -1 TO VFYDL) by a technique we'll explain shortly.
3. The attribute byte for that field is changed from its map default of autoskip to unprotected.
4. Instructions for what to do next are put in the message area.
o The cursor is placed under the surname field for all other types of user requests (ELSE MOVE -1 to SNAMEDL).
o If the request is for an addition:
1. The title is made NEW RECORD. 2. The titles at the bottom of the screen are given a nondisplay attribute. 3. The account field (from the request input) is placed in the output map. 4. Instructions are put into the message area.
o If the request is a modification, the title and the message area are set appropriately.
o If the request is a display, instructions for what to do after the display are put in the message area.
o For all types of requests except adds, the display is built from the record on file (MOVE CORRESPONDING ACCTREC ... through ... MOVE PAY-LINE TO HIST3DO).
o If the request is to print a record, control goes to code at PRINT-PROC that will do the special processing required to write to a terminal other than the input terminal.
o If the request is to display or delete, the attribute bytes of all the data fields that can be entered or changed on an addition or a modification are changed to autoskip. This makes it clear to users that they cannot change these fields in the current transaction.
o For all request types except printing, the map is sent to the input terminal.
We need to use a somewhat different type of SEND MAP command later in the same program, when we have to redisplay the input (menu) map because of some error, or to put a message on the screen. Because the map is already on the screen, it is unnecessary (and wasteful of line capacity) to send what is already there again. So we use the DATAONLY option, and we do not erase the screen:
________________________________________________________________________ | | | EXEC CICS SEND MAP('ACCTMNU') MAPSET('ACCTSET') | | CURSOR DATAONLY FRSET ERASEAUP FREEKB END-EXEC. | | | |________________________________________________________________________|
We also specify FRSET in this command. This prevents fields that were entered during the previous terminal interaction, and not rekeyed, from being sent on the next transmission. That is, only fields that the user changes (probably because of an error) will be transmitted the next time the terminal sends. This reduces line transmission, but it requires the transaction to save the input from the previous execution for the next one. We've a bit more to say about how to use FRSET in the notes that accompany Line 163 of the program source code of ACCT01. You'll find these in "Program ACCT01: initial request processing" in topic 2.10.2.