From: Chris Ringer To: All
After a few very frustrating hours of work on an AS/400 interactive program, I determined why my output was not always sent to the screen. I used indicator- conditioned ERRMSGIDs. The DDS manual says that when this method is chosen, output is not sent to the screen. Apparently, fields defined as OUTPUT on the screen are not sent, although fields defined as BOTH are sent to the screen.
Is there a way around this? I want all output sent-even when I have detected an error. I have an idea for eliminating the ERRMSGIDs. A call to SUBR23R3 retrieves the error text, which I then display in an output field on the screen. But I'd have to do my own reverse image, position cursor, and so on. Has anyone else encountered this ERRMSGID limitation?
From: James Coolbaugh To: Chris Ringer
Anytime you use ERRMSG or ERRMSGID, the data will not be resent to the screen- only the attributes are resent. I agree that this is a frustrating limitation. Here's what I do to get around it.
Prior to rewriting the format-if I have any error messages-I save the indicators, clear them, issue a WRITE to the format, restore the indicators and then issue the EXFMT. I can do this very easily since all my error indicators are in order (e.g., 70-89) and are specifically set aside for error messages on all screens. 2 illustrates the code.
Prior to rewriting the format-if I have any error messages-I save the indicators, clear them, issue a WRITE to the format, restore the indicators and then issue the EXFMT. I can do this very easily since all my error indicators are in order (e.g., 70-89) and are specifically set aside for error messages on all screens. Figure 2 illustrates the code.
This method works very well. You also do not get any screen flash as long as you have DFRWRT(*YES) on the display file and are not using the FRCDTA keyword on the format.
No Output on ERRMSGID
Figure 2 Forcing Output to a Display File with Errors
*. 1 .. + .. 2 .. + .. 3 .. + .. 4 .. + .. 5 .. + .. 6 C MOVEA*IN,70 ERRORS 20 C ERRORS IFNE *ZEROS C MOVE *ZEROS CLEAR 20 C MOVEACLEAR *IN,70 C WRITEFORMAT C MOVEAERRORS *IN,70 C ENDIF C EXFMTFORMAT
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