What are the most significant enhancements to RPG? The answer depends on whom you ask.

One of the interesting aspects of the V6R1 release of RPG is that it highlights the differences in perspective between IBM as the language designer and us as the language consumers. Every IBM document I have seen to date places RPG's new multi-threading support front and center, but I have not met many RPG users who were particularly excited by this news. On the other hand, some of the features that receive less emphasis from IBM (for example, increases in maximum sizes) are frequently greeted by cheers from those in the trenches.

Undoubtedly, the thread support will become more and more important to us all in the future, but right now it is the byproducts of that support that interest me the most. For example, it seems highly likely that the new support for local files in subprocedures was made possible by changes made for thread support, specifically what is known as the "thread-local static storage" model now available for RPG programs (explanation of that term will have to wait for another day).

This will be only a very brief overview of the major features of the new release as I have obviously not had much time to study it in detail and certainly not to try any of these new features out. My teammate Paul Tuohy will be writing more in a couple of weeks.

I mentioned changes in size limits at the start, so I'll review those first. For many of us, the size limitations of pre-V6 RPG IV first became a real issue with the introduction of nested data structures in V5R2 and became even more of a problem when those limits severely restricted the utility of V5R4's XML support. Prior to V6, the maximum size of a field or named DS was 65,535 bytes (64K). With V6, that limit rises to 16,773,104 (16Mb), a significant increase. In a similar vein, there is no longer a limit on the maximum number of elements in an array; however, there is a practical limit since the total size of the array cannot exceed the 16Mb storage limit. So the maximum number of elements is now simply a function of how many will "fit." For example, if each array element is 16 bytes long, then the maximum number of elements would be 1,048,319 (16,773,104 / 16).  Similar increases have been made to the length of varying length fields, as well as Graphic and Unicode fields.

One other data definition feature that I have been eagerly awaiting is the formal introduction of templates. Ever since LIKEDS was introduced in V5R1, I have been using BASED structures as templates in order to provide a clone-able definition that avoids wasting storage. The problem with this is twofold: First, the compiler will still allow me to erroneously reference fields in the template; and second, a Based structure cannot have initialization values defined for it. The keyword TEMPLATE deals with these problems and can be added to DS or standalone field definitions. Indeed it can even be added to file definitions. (You'll understand why that's useful in a moment.)

Speaking of files, I've already mentioned the new support for local files in subprocedures, so let's take a quick look at that. Up until now, all files in RPG programs have been global in nature. They could be used in subprocedures, but the variables that were used were global. This caused many hours of debugging for those who forgot this simple fact, updated a local copy of a file variable in a subprocedure, and couldn't understand why the value on the file was not updated. This situation was eased somewhat in V5R2 when the ability to read into and write from a DS was added. By coding a DS based on the record format (LIKEREC), we were able to avoid some of the problems, but the files remained stubbornly global.

V6R1 brings an end to that limit. Files can now be declared within a subprocedure and indeed can even be passed as parameters between subprocedures and programs for that matter. Although subprocedures now support File specs, they do not support Input and Output specs. Consequently, all I/O operations must be performed using DS. Although not yet added to the compiler, this new approach to I/O offers the possibility that long-name support (i.e., alias name support) may arrive in the future since the major barrier to its introduction was the limit on field length imposed by the generated I and O specs.

Files within subprocedures are opened automatically and closed when the subprocedure returns to its caller. This allows for true recursive behavior in applications such as Bill of Materials and will significantly simplify coding in such endeavors. Coding the STATIC keyword on the file specification can override this behavior. When this keyword is used, the file remains open and storage is shared between invocations.

How do we pass a file as a parameter? Simple: just use the LIKEFILE( ) keyword to define the parameter in the prototype. Note that if you want to directly access the file's variables, you must also pass the I/O DS as a parameter. Under the covers, the compiler is able to access any variables associated with the file that it needs (e.g., the INFDS, the EXTFILE variable, etc.), but you must make your own arrangements to access the data. I think we are going to be seeing a lot of uses for this new capability, but there will also be a number of folks who have performance problems because they didn't think about the impact of the frequent file open/close activity.

I won't say too much more or Paul will have nothing to write about, but I will just briefly mention some of the other highlights:

•·        The compiler now performs implicit conversion between character and UCS-2 (Unicode) variables. This may not seem very important to you today, but as you do more XML work, you will find it considerably simplifies your life.

•·        You now have the ability to use DS I/O with EXFMT by adding the qualifier *ALL to the LIKEREC or EXTNAME DS keywords.

•·        The file keyword EXTDESC has been added to allow you to specify the file definition to be used by the compiler when EXTFILE is used so that you can avoid "file definition not found" at compile time problems.

•·        Support for removing unused variables from the compiled program reduces static storage occupancy.

•·      There are also a number of other, smaller related updates, but these are the big hitters in the release.

Did I forget anything? Oh yes, I would be remiss if I didn't at least mention that the keyword THREAD(*CONCURRENT) can be used on the H-spec to allow the module to be able to run concurrently in multiple threads or to allow multiple threads to run in the module. As I noted earlier, this is going to become more important in the future. For now, it is only really of interest to those of you who build mixed Java and RPG applications.