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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
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.
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:
LATEST COMMENTS
MC Press Online