Embracing RPG IV

Paul Tuohy

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

    Requires Free Membership to View

    Login

    Register today to access targeted resources from our editorial writers and independent industry experts including news, tips, and advice to help you do your job more efficiently and effectively. Stay informed on the hottest topics and biggest challenges faced by IT professionals working with iSeries products and services.

    By submitting your registration information to Search400.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of Search400.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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.

Be free

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:

  • They replace some existing operation codes (e.g. %SUBST for SUBST, %SCAN for SCAN, %XLATE for XLATE). This allows you to use the BIFs within expressions as opposed to having the operation on a separate line and probably necessitating a work field.

    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.

  • They provide new functionality. BIFS such as %REPLACE, %EDITC, %EDITW provide functionality that is extremely difficult to emulate using traditional RPG.

  • They replace the need for resulting indicators on operation codes (%EOF, %FOUND etc.).

  • They are a requirement for data conversion in expressions. BIFs such as %CHAR, %DEC and %INT are used to convert data between different data types.

    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:

  • Use the file BIFs instead of resulting indicators on file operations.

  • Use the Error (E) extender on operation codes instead of an indicator in the low position.

  • Use and indicator data structure (INDDS keyword on the F spec) to map the indicators used in a display file or a print file to named indicators in your program.

    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 compiler uses the prototype to validate the call interface.

  • You can provide a more meaningful name on the call.

  • Prototype keywords (CONST, OPTIONS and VALUE) provide more flexibility for passing parameters then traditional parameter lists.

  • Assuming you use a copy member to include all prototypes in programs (which is the way you should do it) you also have the advantage of documenting all of your call interfaces in one place.

  • Prototyping all program calls prepares you for prototyping subprocedure calls (all subprocedures require a prototype definition).

    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.

    As you progress to using subprocedures qualified data structures become an invaluable tool when passing parameters. See "Qualified data structures: Why you should be using them" for a description of using qualified data structures in RPG IV.

    Use Subprocedures

  • Subprocedures are the biggest change to RPG – ever.

  • A subprocedure is your own BIF, a cross between a subroutine and a called program, a subroutine with parameters or the equivalent of functions in C and other languages.

  • A subprocedure is a subroutine on steroids!

  • Subprocedures can define their own local variables. This provides for "safer" development since only the code associated with the variable can change its content.

  • Subprocedures can access Global variables defined in the main body of the source (this includes access to any files defined in the program).

  • Subprocedures may be called recursively (a subprocedure may even call itself).

  • Subprocedures require a prototype.

    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.

    Embrace

    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.

    This was first published in December 2006

    • Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top