Why move to RPG IV? Well, the need for RPG III programmers is dwindling; most RPG III programmers have become full-time maintenance programmers while others are mostly idle. Currently, trying to find RPG II (yes, I said "2") programmers is like looking for an engineer who can configure the flight computer used to fly the Apollo spacecraft to the moon; it's essentially a lost art. Soon, RPG III programming too will be an unneeded art form.

I suspect that within five years, this will start to be a significant issue to iSeries shops. Do you think five years is a long time? I remember thinking in the early 1980s that the year 2000 was so far away that I needn't worry about date arithmetic.

The RPG IV language is good enough for most business applications for the foreseeable future. It is continually being improved by IBM (often too rapidly for its own good, but that's another story), and it is supported by third-party vendors worldwide.

There is no compelling reason to leave your applications in RPG III. Those RPG III programmers who blow off RPG IV are just lazy or afraid. If the reason is laziness, shame on you; move to RPG IV anyway. And as one who advocates facing your fears, I say, jump in that pool and swim!

I may sound like a fear-mongering politician during an election year, but if you don't move to RPG IV and start enhancing your applications more effectively (by such means as adding Web-based interfaces), your job may be going offshore. There is no way to create cool new applications using RPG III anymore. The support and infrastructure just don't exist.

Moving to RPG IV

Moving to RPG IV is, with one major exception, as easy as running the CVTRPGSRC command. You can simply convert to RPG IV from RPG III and plug in the new source member without any impact to your existing job stream. Then, from that point forward, you can enhance the application using RPG IV syntax and infrastructure.

The "major exception" is when you move from the default RPG IV to things like subprocedures and activation groups. In most cases, you can also simply start using the new functionality added to the application after it is converted to RPG IV. But there is one strange situation where you have to worry about CL calling the RPG IV program.

The OPNQRYF Issue

The issue is when a CL program calls your RPG application. When you move the RPG III application to RPG IV, you'll have no problem replacing the RPG III program with the RPG IV program, running it in the default activation group. The next logical step is to move that RPG IV program into a named activation group, thus having it run in an activation group other than the one in which the CL program is running.

The problem occurs when the CL program calls an OPNQRYF command just before calling the RPG IV program that is going to use the open data path generated by the OPNQRYF command. By default, it should work, but it does not.

The problem is the implementation and the documentation. The implementation is "wrong" because it does not work like the OVRDBF command. That is, the OVRDBF command works fine with the default value of OVRSCOPE(*ACTGRPDFN), but the OPNQRYF command does not work with that default value.

Here's what the online documentation says about the OPNSCOPE parameter on the OVRDBF and OPNQRYF commands:

The OVRDBF OPNSCOPE parameter: "Specifies the extent of influence (scope) of the open operation." *ACTGRPDFN means: "The scope of the open operation is determined by the activation group of the program that called the OVRDBF command processing program. If the activation group is the default activation group, the scope is the call level of the caller. If the activation group is a non-default activation group, the scope is the activation group of the caller."

The OPNQRYF OPNSCOPE Parameter: "Specifies the extent of influence (scope) of the open operation." *ACTGRPDFN means: "The scope of the open operation is determined by the activation group of the program that called the OPNQRYF command processing program. If the activation group is the default activation group, the scope is the call level of the caller. If the activation group is a non-default activation group, the scope is the activation group of the caller. In a multithreaded job, only those opens within the same thread and within the same activation group can share this ODP."

With the exception of the last sentence in the OPNQRYF version, the online documentation is identical for the OPNSCOPE parameter for both commands.

This means that you should be able to leave your CL programs running in the default activation group and have your RPG IV programs running in a named activation group (or a *NEW activation group). In practice, however, I found that while OVRDBF performs as expected, OPNQRYF does not. OPNSCOPE(*ACTGRPDFN) doesn't seem to work on OPNQRYF. It should simply *CALLLVL. Even though *CALLLVL is not an option on the command, it is defined by the words "call level" in the documentation.

I know that if you do an OPNQRYF OPNSCOPE(*ACTGRPDFN) while in CL running in the default activation group and then call an RPG IV program running in a named activation group, the RPG IV program will not see the ODP of the OPNQRYF. I don't know if this is wrong, but it's certainly confusing.

The bottom line on this problem is that (a) IBM should fix this problem either by creating a new option for the OPNQRYF OPNSCOPE parm or by fixing the existing one and (b) people really have to stop using OPNQRYF and start using embedded SQL.

RPG III to RPG IV

Aside from this one issue, moving to RPG IV is viable, productive, and beneficial. Programmers will keep their jobs, employers will retain and attract better programmers (i.e., RPG IV programmers), and the world will be a happier place.

RPG IV has a huge support structure, including books, magazine articles, online newsletters like this one, formal education and training, tons of examples, third-party add-on libraries of functions, and of course, ongoing enhancements by IBM.

If the bulk of your application base is still in RPG III, start putting together a migration plan today. Phase 1 of that plan is to move to RPG IV and use the default activation group (thus avoiding the need to add the OPNSCOPE keyword to the OPNQRYF command). Phase 2 is to move the interactive applications to a named activation group so you can take advantage of subprocedures, service programs, and CGI programming techniques.

Now get back to work!

Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.