ILE RPG and free-format have been around for years. However, not everyone is taking advantage of these and other features of modern RPG. Take the quiz below and find out how much you really know about modern RPG programming.

Modern RPG implies modular and structured programming techniques: using modules and service programs, procedures, functions, and so on. However, using procedures and functions generally requires passing parameters between them. That's where things can start to get a bit complicated. Unexpected errors start occurring after a function call, and after hours of fruitless investigation, you finally realize that the function call changed a value it shouldn't have. There are two keywords, VALUE and CONST, to prevent that from happening. That brings us to the first question of this quiz:

Which keyword is best to keep your parameters safe: VALUE or CONST?

1. VALUE
2. CONST
3. It depends

If you replied either a or b without hesitating, then let me tell you that you're wrong. The correct answer is c, "It depends." Let's very briefly go over how each of these keywords works to explain why c is the correct answer:

• VALUE is nice because you're 100 percent sure that the original variable is not changed (unless something really, really weird happened). However, it's not a good idea to use this keyword with big parameters or intensively used procedures because the system will have to copy the parameter's contents to a new variable every single time the procedure is called. That's the way to ensure that the original variable remains untouched.
• CONST is also nice because there's no content copying, so the procedure gets called immediately, regardless of the size of the parameters; only the pointers are passed. It's faster and also "cleaner" in the sense that you're not allowed to intentionally change the parameter's contents. At compile time, the system checks and flags any attempts to change the content of a parameter defined with const.

As you can see, both keywords have pros and cons. You need to carefully define your procedure's parameters, taking into account the parameters' sizes, what you're going to do with them, and how often the procedure will get called, if you know that in advance. I'm sure that some readers won't agree with this answer, so feel free to speak your mind in the "Comments" section below.

Some programmers who have moved to free-format RPG complain that the language is being held back by some annoying constraints. Let's see how much you know about free-format RPG, starting with the question below:

Is it possible to write the header section of an RPG program (the H-specs) in free-format?

1. Nope, you're still stuck with ugly fixed-format H-specs in your "modern" RPG code.
2. Yes, you can!

The correct answer is b. One of the least-known parts of free-format RPG was introduced with V7.1 TR7: the ability to write control, file, and definition specification lines (H-, F-, and D-specs) in free-format. Let's look at an example of a control specification migration from fixed- to free-format.

The following is a group of "traditional" control specifications:

H CURSYM('$') DEBUG(*YES) DECEDIT('. ') DATEDIT(*MDY) DATFMT(*MDY/)

H TIMFMT(*ISO) COPYRIGHT('(C) Copyright ACME Company - 2015')

This becomes a neat piece of code in free-format:

Ctl-opt CURSYM('$')

         DEBUG(*YES)

         DECEDIT('. ');

Ctl-opt DATEDIT(*MDY)

         DATFMT(*MDY/)

         TIMFMT(*ISO);

Clt-opt COPYRIGHT(' (C) Copyright ACME Company - 2015');

The indentation might seem like an idiosyncrasy, but it's there for a reason: future maintainability. If I wanted to change the option used in DATFMT, for instance, I'd have to rewrite the fixed-format lines, while the same operation in free-format is much simpler. How cool is that?

Another common complaint is related to the operation codes that people can't find in free-format, which brings me to the next question:

What are the free-format replacements for TAG, GOTO, and CABXX?

1. The %JumpHere, %JumpTo, and %JumpWhenxx BIFs
2. There aren't any. Restructure your spaghetti code ASAP.

The correct answer is b. These three operation codes don't have replacements, direct or indirect, in free-format—and if you ask me, that's a good thing. Let's do a quick refresher, starting with the last of the three: CABXX, the "Compare and Branch" operation code, has been around for ages; it's one of the workhorses of "old" RPG. If you're not familiar with it, the functionality provided by CABXX is similar to CASXX; the difference is that it doesn't execute a subroutine, like CASXX. Instead, it "jumps" to a label somewhere else in the code.

TAG (the way to indicate a label) and GOTO (another way to jump to a label) were dropped for the sake of readability (and getting rid of the dreaded spaghetti code, hallmark of older versions of RPG). This means you'll need to reengineer your code to "convert" the CABXX, TAG, and GOTO operations to free-format. Let's explore the options.

Sometimes, a TAG and a GOTO delimit a piece of code that could be a subroutine or even a procedure in better-structured source code. Using the CASXX free-format alternative (an IF statement surrounding an EXSR instruction) might be a solution for these cases. However, there are times when you just need to "jump" to a particular place in the code—leave a cycle or a subroutine, for instance. For these cases, there is ITER (iterate), which jumps to the top of a loop. That can be any type of loop: DOWXX, DOUXX, or FOR. There's also LEAVE, which jumps out of the loop, and LEAVESR, which (you guessed it) leaves the subroutine.

For the rest of the GOTO situations, you need to take a good hard look at the code and decide what to do. It's not the best of solutions, but you can decide to leave it as is (for a while, at least), because you can mix fixed- and free-format code, as long as you signal the beginning and end of your free-format code with the appropriate directives. I'm not encouraging you to leave those GOTOs permanently—just until you get some experience with the whole ILE thing.

The Open Query File (OPNQRYF) command, along with the GOTO and TAG operations codes, sits at the top of the RPG programmer's worst nightmare list because what started as a good, simple idea became a huge mess in no time. Someone has to maintain that mess … and it's never easy. This begs our next question:

Is there a way to get rid of the dreaded OPNQRYF in modern RPG?

1. Not yet, but there's still hope.
2. Yes, by using an SQL cursor in your RPG program.

Again, the correct answer is b. A cursor is a way to use an SQL SELECT statement as if it were a keyed file. In a real-life OPNQRYF, big QRYSLT values are common, leading to nightmarish commands that don't always perform as we'd wish. By dynamically defining data access (or cursor), you can replace the dreaded OPNQRYF with something simpler and much easier to maintain. The solution is defining a flexible cursor using host variables in the DECLARE statement.

Let's say I want to define a cursor named mainCursor that reads data from a file named InvMst. I want to be able to indicate the warehouse ID (that's field WHID) dynamically. The cursor's DECLARE statement looks like this:

/Free

   Exec SQL

     DECLARE mainCursor CURSOR

     FOR

     SELECT InvMst.ItemID, ItemDesc, ExpDate

     FROM   InvMst InvMst

     INNER JOIN ItmMst ItmMst ON InvMst.ItemID = ItmMst.ItemID

     WHERE WHID = :K_WHID;

Notice the line in bold? The WHERE clause with host variables (in this case just one, but you can use as many as you want) replaces the QRYSLT part of OPNQRYF. This variable's value is not known when the cursor is declared, but that's not a problem, because the DECLARE statement is more concerned with the SELECT clause—it needs to know which columns are going to be part of the temporary result table it needs to create. K_WHID matters when the FETCH statement is executed. That's when K_WHID's value is going to be used to replace the host variable name in the statement.

Creating a replacement for an OPQRYF is feasible, assuming that you are able to understand what's in the QRYSLT part of OPNQRYF. It can be as easy as "translating" the QRYSLT code to the appropriate SQL comparisons and putting them in the WHERE clause of the DECLARE statement.

If you answered any of these questions incorrectly, you might not know as much about modern RPG programming as you thought. My book, Evolve Your RPG Coding: Move from OPM to ILE ... and Beyond, explains these and many other topics in depth, with examples. It covers the whole OPM-to-ILE journey:

• How to go from monolithic programs to flexible modules, programs, and service programs
• How to write structured, well-documented, and maintainable code
• How to smoothly migrate from fixed- to free-format RPG

Additionally, the book provides one of the most comprehensive chapters about SQL ever written for an RPG book. It covers DML and DDL, as well as embedded SQL in RPG programs, and its opposite: the creation of stored procedures and user-defined functions from RPG code. Then it goes beyond ILE, discussing application modernization, with special emphasis on database and user interface modernization. These are broad topics for which the book provides guidelines, tools, and strategies to help you pursue a successful modernization initiative.