TechTalk: Multiple Error Message Processing

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Perhaps the best example of how RPG programming methods vary is the variety of ways to handle screen error messages. In many programs when a user fills a screen with data and presses enter, he or she is presented with a single error message, only to find that when he or she presses enter again, another message is displayed about the data in some other field. This error checking process is fairly common, but is not always the most efficient way to display multiple errors.

Using a subfile for the display of error messages lets you present a one-line-at-a-time subfile display that allows you to roll through multiple error messages. When looking at the first message, you know there are other messages to look at if you see a plus sign at the right of the message.

The following code samples illustrate how to code for multiple error messages by using a subfile. They are simple enough for you to integrate them easily into your coding style. Before long, the use of those one-at-a-time methods will become less common.

1 contains the record formats that must exist in the display file in order to display the errors. These record formats can be added "as is" to any DDS and require no changes to work in most situations. The only limits they place on your screens are that line 24 must be reserved for use by the error subfile, and indicator 99 must not be used elsewhere in your program or DDS.

Figure 1 contains the record formats that must exist in the display file in order to display the errors. These record formats can be added "as is" to any DDS and require no changes to work in most situations. The only limits they place on your screens are that line 24 must be reserved for use by the error subfile, and indicator 99 must not be used elsewhere in your program or DDS.

The RPG/400 lines in 2 must exist in your program in order for you to set up the #MSG table and process the error subfile before and after each time a display is processed. Note that the only line that may need to be changed is the MOVE 'SAMPMF' #MSGFIL, where SAMPMF is the name of the message file being used.

The RPG/400 lines in Figure 2 must exist in your program in order for you to set up the #MSG table and process the error subfile before and after each time a display is processed. Note that the only line that may need to be changed is the MOVE 'SAMPMF' #MSGFIL, where SAMPMF is the name of the message file being used.

The library in which the CL program resides (see 3) must exist in the library list of the person who will be executing your program. The ERRCTL25 program is used to clear any accumulated messages in the program message queue, and send any new error messages.

The library in which the CL program resides (see Figure 3) must exist in the library list of the person who will be executing your program. The ERRCTL25 program is used to clear any accumulated messages in the program message queue, and send any new error messages.

In order to send the appropriate messages, add the following code for each error that you are processing.

C ADD 1 E C MOVE 'AAA0001' #MSG,E

where AAA0001 is the message number of the error. Then, just before you re-display the screen which is in error, the following subroutine should be called to display the error subfile:

C EXSR #ERDSP

After the screen is displayed and control has returned to the program, the following subroutine should be called to clear the subfile for the next set of field checking routines:

C EXSR #ERCLR

An additional consideration is that your screen has the OVERLAY keyword so that the subfile is not erased when your screen is written to the display.

Bernal Schooley Mount Prospect, Illinois


TechTalk: Multiple Error Message Processing

Figure 1 Display file SFLMSGDF

 A* 90/08/07 15:12:52 RICHARD REL-R02M00 5728-PW1 A DSPSIZ(24 80 *DS3) A R #ERRSFL SFL SFLMSGRCD(24) A MSGKEY SFLMSGKEY A #PGMNM SFLPGMQ A R #ERRCTL SFLCTL(#ERRSFL) A CF03(03) A SFLSIZ(10) SFLPAG(1) A SFLINZ SFLDSPCTL A 99 SFLDSP SFLEND A N99 SFLCLR ERASE(#ERRSFL) A OVERLAY A #PGMNM SFLPGMQ A R SCRN1 A* 90/08/07 15:12:52 RICHARD REL-R02M00 5728-PW1 A 2 2'line' A 2 7'2' A 3 2'line' A 3 7'3' A 4 2'line' A 4 7'4' A 5 2'line' A 5 7'5' A 6 2'line' A 6 7'6' A 7 2'line' A 7 7'7' A 8 2'line' A 8 7'8' A 9 2'line' A 9 7'9' A 10 2'line' A 10 7'0' A 11 2'line' A 11 7'11' A 12 2'line' A 12 7'12' A 13 2'line' A 13 7'13' A 14 2'line' A 14 7'14' A 15 2'line' A 15 7'15' A 16 2'line' A 16 7'16' A 17 2'line' A 17 7'17' A 18 2'line' A 18 7'18' A 19 2'line' A 19 7'19' A 20 2'line' A 20 7'20' A 20 60'Enter' A 20 66'an' A 20 70'A' A FLD001 1 B 20 76 A 22 11'F3=Exit' A 23 2'Line' A 23 7'23' A 21 2'line' A 21 7'21' A 1 2'line' A 1 7'1' 
TechTalk: Multiple Error Message Processing

Figure 2 RPG program SFLMSGRPG

 ************************************************************************** * PROGRAM NAME: SFLMSGRPG * AUTHOR: Bernal Schooley * DATE CREATED: 09/90 * PURPOSE: Example of processing multiple error messages * through the use of a subfile. ************************************************************************** FSFLMSG CF E WORKSTN E ARM 1 7 7 E #MSG 25 7 I* Get this program name I SDS I *PROGRAM #PGMNM C DO 7 I 10 C MOVE ARM,I #MSG,I C END * C *INKC DOWNE'1' C EXFMTSCRN1 C FLD001 IFEQ 'A' C Z-ADD7 E 20 C* SAMPMF is the name of the message file containing user messages C MOVEL'SAMPMF' #MSGFL 10 C EXSR #ERDSP C EXSR #ERCLR C END C END * C SETON LR C #ERDSP BEGSR C E IFNE 0 C* Call generic CL program to send message to program message C* queue. C CALL 'SFLMSGCL' C PARM #MSGFL C PARM #MSG C PARM #PGMNM C PARM E C MOVE '1' *IN99 C EXFMT#ERRCTL C END C ENDSR C #ERCLR BEGSR C E IFNE 0 C MOVE *BLANKS #MSG C Z-ADD*ZERO E C MOVE '0' *IN99 C WRITE#ERRCTL C END C ENDSR ** User defined message numbers stored in message file SAMPMF USR0001 USR0002 USR0003 USR0004 USR0005 USR0006 USR0007 
TechTalk: Multiple Error Message Processing

Figure 3 CL program SFLMSGCL

 SFLMSGCL: + PGM PARM(&MSGFL &MSGTBL &PGMNM &E) DCL VAR(&MSGFL) TYPE(*CHAR) LEN(10) DCL VAR(&MSGTBL) TYPE(*CHAR) LEN(175) DCL VAR(&PGMNM) TYPE(*CHAR) LEN(10) DCL VAR(&E) TYPE(*DEC) LEN(2 0) DCL VAR(&MSG) TYPE(*CHAR) LEN(7) DCL VAR(&X7) TYPE(*DEC) LEN(3 0) VALUE(1) DCL VAR(&X) TYPE(*DEC) LEN(2 0) VALUE(1) RMVMSG PGMQ(*SAME &PGMNM) CLEAR(*ALL) LOOP: + CHGVAR VAR(&MSG) VALUE(%SST(&MSGTBL &X7 7)) SNDPGMMSG MSGID(&MSG) MSGF(*LIBL/&MSGFL) TOPGMQ(*SAME &PGMNM) CHGVAR VAR(&X) VALUE(&X + 1) CHGVAR VAR(&X7) VALUE(&X7 + 7) IF COND(&X *LE &E) THEN(GOTO CMDLBL(LOOP)) ENDPGM 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: