Technology Refresh 7 (TR7) provides quite a few new features, and this is the first article devoted to some of those changes.

TR7 has a wealth of additional features and functionality for various parts of the IBM i operating system, and in coming articles I plan to cover as many of them as possible. But since the focus of today's article is RPG, it makes sense to stick with the enhancements in RPG-related compilers. So let's take a look at what has happened.

Getting /Freer Every Day

The title of this paragraph is tinged with irony, since part of the evolution of free-format RPG is to actually get rid of the /free (and /end-free) statements in RPG. But I'm putting the cart just a little bit ahead of the horse here, so let me try to present the changes in an orderly fashion.

If you haven't been asleep the last decade, you've heard about free-form RPG, in which the calculation specifications have been unshackled from their fixed columns and allowed to roam freely across the source member. The resulting code looks a lot more like something you would expect to see in a Java or C class, albeit with some rather noticeable differences (such as the lack of curly braces). Here's an example. We're defaulting an operation to be rejected and then overriding it to be allowed for a security officer (this is a very small piece of a web authorization code).

     C               eval     Authorization = Reject

     *

     C              if       user = SecurityOfficer

     C               eval     Authorization = Allow

     C               else

In free-form RPG, the code is more C-like:

     /free

      Authorization = Reject;

      if user = SecurityOfficer;

       Authorization = Allow;

      else;

However, even with the new look, there's a certain amount of clumsiness in the implementation. Immediately noticeable even in the brief segment above is the requirement of the use of the /free directive to switch between fixed-format and free-format syntax (and the corresponding /end-free directive—not shown—to switch back to fixed format). Also, the original free-format RPG syntax affected only calculation specification (C-specs). Other specifications—header, file, data, input, and output, as well as the new procedure specification—all required a fixed-format syntax. When I teach RPG and the Rational development tools, I always make light of the fact that one of the capabilities of the advanced GUI development tools is the ability to still prompt for a fixed-format F-spec.

Figure 1: You can still prompt for a fixed-format F-spec if you want to.

But really, this is needed, because I can never remember where to put the K to indicate keyed access or the A that identifies file addition. And as I use more and more free-format RPG, it's harder to remember. And while I suppose if I tried hard enough I could remember them, it's so much easier to just write this:

      dcl-f envdef keyed;

That's all that is required to create a file definition for the ENVDEF file. I'll have to remember a few new keywords such as USAGE( *INPUT | *OUTPUT | *UPDATE | *DELETE) and the KEYED keyword you see in the example, which identifies the file as having keyed access, just like the old K in column 34, but I find keywords a lot easier to remember than fixed column positions. Anyway, two of the old-fashioned specification types, namely header and file, are each replaced by a specific new free-format opcode: header by the ctl-opt operation and file by the dcl-f operation.

Next in the list is the newer procedure specification. The P-spec is replaced by the dcl-proc operation, but this is a little more complex in that the dcl-proc just opens the specification; it requires a matching end-proc operation to close the block. Everything between those two statements is considered the body of the declaration. In a more C-like implementation, you might expect to see the body of the procedure delimited by curly braces ("{" and "}"), but the RPG compiler team decided to stick with the opcode and semi-colon approach. Most RPG programmers should feel comfortable with that sort of blocking, mimicking as it does the if/endif and dowhile/enddo constructs we know already.

Finally, we get to the data definition specification. The D-spec is a complex, multi-functional specification, and because of that, it's broken apart into multiple free-format operation codes. Generally, though, the operation codes mirror the definition types: one operation exists for each of the primary definition types of constant, data structure, standalone field, prototype, and procedure interface. If you're familiar with the fixed-format D-specs, you know that each has its own definition type specified in columns 24 and 25 of the specification, such as C for constant or PI for procedure interface. The new free-format operation codes correspond directly to those types, with dcl-c used to declare a constant and dcl-pi to define a procedure interface. Other operations follow that pattern. Additionally, two other operations provide the functionality for the two data definitions with blank definition types: data structure subfields (dcl-subf in the new syntax) and procedure parameters (identified by dcl-parm).

Note also that those definitions that can have sub-definitions (data structures, prototypes, and procedure interfaces) are all closed by an end specification. For example, a data structure might look like dcl-ds, one or more dcl-subf intrsuctions, and an end-ds.

      dcl-ds reference;

       dcl-subf program char(10);

        dcl-subf library char(10);

        dcl-subf filename char(10);

      end-ds;

In another article, I'll go through some of the more subtle nuances of the new syntax (for example, the dcl-subf operation is optional, much the same way that eval is optional in free-format calculations).

Final Twists

There are a couple of last minor changes to the syntax. First, as I've alluded to already, the /free and /end-free are deprecated. You can still use them, but they're ignored, and in fact you can now intersperse fixed-format and free-format RPG code with impunity. It makes sense, since the logic is pretty simple: if there's a C in column 6, it's a fixed-format statement, and if there's a blank, it's free-format. Extend that out to the rest of the source and basically column 6 identifies each line as either fixed- or free-format. This does lead to one byproduct that could easily be abused: you can now put old-fashioned fixed-format code including GOTOs, TAGs, and even the dreaded MOVEs in the midst of your free-format code. You could always do that, of course, but prior to TR7 you had to at least surround the deprecated opcodes with an ugly /end-free and /free block.

And finally, you don't have to have your F-specs ahead of your other declarations. Feel free to intersperse your dcl-f, dcl-c, dcl-s, and dcl-ds as you see fit.

Please note that you'll have to apply the TR7 PTF before all of this free-format goodness becomes available. Also, it's not yet clear when these syntax changes will be recognized by the Rational development tools. I think it's safe to say, though, that you won't ever be seeing them in SEU.