By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
You have made the move from RPG III to RPG IV. You have gotten used to mixed case code, you are using EVAL operations and you even use the odd Built in Function. You may even have tried a couple of subprocedures. You are using RPG IV.
There is that certain sense of familiarity about it all. Even though it is RPG IV there is still a certain feeling of RPG III about it. This is not really surprising, you say, since RPG IV is an extension of RPG III.
RPG IV is much more then just an extension of RPG III. Enhancements in the language provide new ways of doing things, which, in turn, necessitate a change in day-to-day coding practices. There are habits that you need to change.
This is in the same way that RPG III was much more then an extension of RPG II. Those of us who programmed on the System/34 and System/36 remember when the RPG cycle was a necessity in every program and how we had to kick the cycle habit when we moved to RPG III.
In my humble opinion, these are the seven features of RPG IV that you should learn to use in order to embrace RPG IV-- as opposed to simply using it (I have described some of these features in previous tips).
Use the right tools
Using the right tools is not a feature of RPG IV but it is a necessity. If you are still using PDM/SEU to maintain your source, I suggest you stop. You should be using WebSphere Development Studio Client (WDSC) and or CODE as your development environment as opposed to PDM. The features and productivity gains of using WDSC far outweigh the effort of installing it -- and that is all you have to do, install it.
Free form calculations are the future of RPG. It is already the case that certain features are only available in free form (use of the %KDS BIF, specifying a list of key fields on a file operation, proper use of the XML-INTO operation) and this will become the norm in the future.
Proper use of free form also makes for more readable code -- you have the ability to indent code and you control the "white space."
See "Free form RPG: Are you /FREE?" for a description of using Free Form in RPG IV.
Use built in functions
The number of Built in Functions (BIFs) available in RPG IV increases with every release of the compiler. Starting with a measly seven BIFs on the first release (V3R1) there are now over 70 BIFs available in RPG IV.
The main benefits of BIFs are:
This is also one of the considerations for free form. Certain operation codes are replaced by a BIF as opposed to having a free form equivalent of the operation code.
Consider the snippet of code shown in Figure 1 which uses the %SCAN, %TRIMR and %SUBST BIFs to reverse a name:
The use of the BIFs allows the reversal with two expressions (it can actually be done in one but it is much harder to read). Compare this to the traditional use of the SCAN, CAT and SUBST operations shown in Figure 2.
Which of the two do you find easier to understand? If you said the second one, please stop reading now.
Most importantly, BIFs get you used to a style of programming that will need to be second nature when you start writing your own functions i.e. subprocedures.
Get Rid of RPG Indicators
Stop using RPG indicators -- the only one that is still required is *INLR.
To stop using RPG indicators you need to:
See "The truth about indicators" for a description of indicator usage in RPG IV.
Use Prototyped Calls
Replace all of your CALL (and CALLB) operations with CALLP operations.
The main advantages of prototyped calls are:
The snippet of code shown in Figure 3 demonstrates the flexibility of prototyped program calls (the prototype would be coded in a copy member).
See "The call of the prototype" for a description of prototype usage in RPG IV.
Use Qualified Data Structures
Qualified data structures provide a means of defining standard structures. Duplicate structures can easily be defined using the LIKEDS keyword. The use of subfields is self documenting since the subfields must be qualified with the data structure name.
The snippet of code shown in Figure 4 demonstrates the definition and use of qualified data structures.
The best advice I can give you about using subprocedures is to start using them instead of subroutines. There is a little more coding involved because subprocedures require a prototype but there is the immediate advantage of being able to pass parameters and define local variables.
The most important advantage of using subprocedures is that it gets you in the right frame of mind. The biggest benefit of subprocedures comes within ILE. Subprocedures are a feature of ILE and whereas you may start using subprocedures as a replacement for subroutines you will quickly adapt to writing callable functions that are placed in modules in service programs. This is the tip of the iceberg to the more modular design offered by ILE.
Programmers are creatures of habit; we know that it is easier to copy a piece of code and change it then it is to re-write it from scratch.
But maybe the time has come to start copying new pieces of code!
Do you have any features that you think should be added to the list? Let me know.
About the author: Paul Tuohy is CEO of ComCon, an iSeries consulting company. He is the author of "Re-engineering RPG Legacy Applications", "The Programmers Guide to iSeries Navigator" and the self teach course "iSeries Navigator for Programmers". He is also an award winning speaker who speaks regularly at US Common conferences and the renowned RPG Summit conferences.