The data areas used in an RPG program are not normally written out if the program ends abnormally. So the UDS style of defining data areas is not suitable when you need a data area written out, even if the program crashes. I've come up with a way to solve this problem.
You might use my technique in an error recovery situation. For example, you might keep track of the last record number processed in a data area. If the program ends abnormally, the program can look at the data area to tell which record to begin with the next time it's run. If you try to lock and update the data area on every record read, you'll use a lot of system resource.
My method works by locking the data area at the beginning of the program. It then increments a counter to reflect every record read and codes an update to the data area-once for a normal end of the program and once for an abnormal end. You can see an example of this in 1. I've found this technique to be quite useful.
My method works by locking the data area at the beginning of the program. It then increments a counter to reflect every record read and codes an update to the data area-once for a normal end of the program and once for an abnormal end. You can see an example of this in Figure 1. I've found this technique to be quite useful.
- T. V. S. Murthy
TechTalk: Get the contents of a data area written out, even if the program ends abnormally.
Figure 1: Updating a Data Area After an Abnormal End in RPG III
*=============================================================== * To compile: * * CRTRPGPGM PGM(XXX/ABD001RG) SRCFILE(XXX/QRPGSRC) * *=============================================================== *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 C *ENTRY PLIST C PARM TYPE 1 C* C MOVE 'N' ENPSSR 1 C *NAMVAR DEFN DTAARA DTAVAR 10 C *LOCK IN DTAVAR C* C Z-ADD*ZERO ZERO 30 C TYPE IFEQ 'A' C DIV ZERO ZERO C ENDIF C* C MOVEL'NORMAL' DTAVAR C OUT DTAVAR C MOVE *ON *INLR C* C *PSSR BEGSR C* C ENPSSR IFEQ 'N' C MOVE 'Y' ENPSSR C MOVEL'ABEND ' DTAVAR C OUT DTAVAR C ENDIF C MOVE *BLANKS RTNPNT 6 C* C ENDSRRTNPNT *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
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