Heard about the new positionless RPG support that's coming out for V7.1? No? OK, then have you heard about Pluto? That's messed up. But we're going to focus on just the former.

If you're not already using positionless RPG, the so-called RPG /free, then what are you waiting for? It's easy to learn, and just the ability to indent and re-indent (which makes it so much easier to see the structure and flow of your program) is enough to make you switch from COPR (Crappy Old Positional RPG). And there's lots more in /free to take advantage of. You can easily be up and running with it in a week or so. The most difficult thing is taking that first step and typing a line of code without the starting C.

To learn /free, I recommend either Jim Martin's concise book, Free-Format RPG, or else any number of tutorials that you can find online, including a four-tutorial set that I have on my website.

Unfortunately, even if you were using /free for the program logic, you still needed the formal, positional F-, D-, and other specs. And you had to use the /free and /end-free delimiters in your program to identify what code was free-form. But now a new PTF is available with V7.1 that will change all that. It's being announced in conjunction with Technology Refresh 7 (TR7), but it's really a PTF to the RPG compiler for 7.1 (PTF SI51094). The bad news is that this enhancement to the compiler is only for 7.1, but the good news is you can just install this PTF without having to do the whole TR7 (but you need to be on 7.1).

Why Are They Doing This?

Some of you, especially if you're not using /free now, may be wondering why IBM is bothering to do this. Why do /free at all? And especially, why not just leave the F- and D-specs the way they are?

Well, if you're using /free now, I'm sure you'll agree that it makes the whole program so much more readable. I love the ability to indent, I'm crazy about the new way you can handle keys without having to define a key structure in the C-spec, I like not having indicators all over the place, etc. But the main rationale for /free from an IBM point of view is making the language easier to learn and making it look less freaky to people completely new to RPG, particularly people who know languages that are not positional. And today, that would be almost everyone who can code. Style isn't everything, but it is hard to convince someone that RPG is a modern language when it doesn't work unless everything is in the proper column. Can anyone spell p-u-n-c-h-c-a-r-d?

And converting the H-, F-, D-, and P-specs to free-format is a natural extension. No one has to learn any of the single-character code values that are part of the positional structure, and it just makes things easier all the way around.

Is everyone crazy about this? No. I have to be honest. And I hadn't thought too much about it until I saw a discussion in the LinkedIn AS/400 Professionals group. Started by John Polucci, the discussion talks about the extension of free-form and wonders if the time spent on that wouldn't have better been spent on other RPG extensions, such as string-handling, GPS positioning, mobile device support, and the oft-referenced but as yet undelivered module oriented around "dating above your league" application. It's an interesting discussion, although (like most LinkedIn discussions) it veers off into other topics after the fourth or fifth post—people do like to talk—but there seems to be an even split between those who think this is worthwhile and those who think RPG should be expanded to do things normally done by more web-oriented languages. Good luck on that one. In my opinion, we're entering an era where the quest for the holy grail of languages (the one language to bring them all) has been called off, and we see the need for different languages for different tasks. And as such, updating RPG so that it's not positional is a good move. Let's face it; most of the programming world is web-based, not mainframe-based. We're the minority, and we need to encourage people to see what RPG can provide. Setting up barriers to that does us no good.

What Does This PTF Provide?

Well, as you might have guessed, it extends the free-format support that was given to C-specs to H-, F-, D-, and P-specs. But it also does one other thing.

Up to this point, you had to start your logic part of the program with the tag "/free" in the appropriate column. And then, if you interspersed COPR C-specs in with your beautiful free-form code, you had to end the free-form code with "/end-free," and then when you wanted to start it again, you had to put in another "/free," and so on.

This PTF will allow you to eliminate entirely the /free and /end-free tags. You don't need the /free at the start of your free-form code, and you can still intersperse regular C-specs right in with your free-form code if you want to. And there are times when you might just need to do that. As Barbara Morris pointed out in her talk at the recent Common Virtual Conference (More Freedom for RPG: Free Form H, F, D, and P Specs), if you're using a "Whenever" clause in an SQL statement, it uses a GOTO to point to a tag, and since tags are not supported in /free because they're evil, you have to use a regular C-spec to code that up.

We'll see later that this also means you can mix positional D- or F-specs with the new free-form data structure statements. I'm not quite as crazy about doing that, but freedom is sometimes always a good thing.

Free-Form Restrictions

It should be pointed out that there are still a couple of restrictions related to the free-ness of your RPG program even with this PTF.

In your source, you're limited to the 80-byte column. I personally don't see that as much of a restriction; most of the time, if I have a very long command statement, I want to put it on several lines just for readability (you know, like breaking an If statement up so that the various operators and values line up vertically).

Also, the new positionless support does not extend to I- and O-specs. Those would have to be coded in old positional format. Again, that doesn't affect me too much. Can't remember the last time I used an I-spec, and pretty much the same thing is true for the O-spec. Nobody wants reports; they want a spreadsheet. And if you do code a paper report, you probably want to use an external print file for it anyway rather than O-specs.

Almost finally, /free will not handle things within a program that are based on the RPG cycle. You have to code that up using positional RPG. Of course, if you need to do this, then you can use SQL to mimic that functionality within your free-form program.

And, really finally, don't forget that all of this applies only if you are on 7.1. You don't have to be on TR7, but you do have to be on 7.1. The PTF will not work with any other release. Not sure if I mentioned that already.

General Rules for How This Will Work

So how does this work? You know, the F, D, H, P stuff?

Well, you can put them right where you put them now—at the front of the program. Of course, they're not called "specs" anymore, although I probably will for the next seven or eight years. They are control statements: option control statements, file control statements, data structure control statements, etc. Each of them starts with an op code that identifies what type of control statement it is. And each of them ends with a semicolon, the standard way to end a free-form statement.

What's interesting is that you can embed "if" statements right into these control statements. We'll look at this more when we get to the file control statements, but just kind of file that away for future reference.

H-Specs

So, let's get going. And let's start with the H-specs, the spot where we give the compiler instructions on how to handle this program. In /free, this is covered by the option control statement, which starts with ctl-opt and ends with a semicolon. In between are whatever keywords you want to list. You may have one, or many, or no option control statements, and if you do have some, you can also have H-specs mixed in with them.

ctl-opt;

If you specify just the statement keyword with no parameters, then all it accomplishes is to keep the compiler from looking for a control specification data area.

Most of the time, you'll probably want to issue parameters with the keyword. Some of the common keywords and parameters you might use are as follows.

option (*srcstmt : *noiodebug);      

or

opt-ctl       dftactgrp(*NO)

             actgrp(*NEW);

Other parameter keywords that you might use include the following:

ccsid(*char:*jobrun)

dftactgrp(*no)

alwnull(*usrctl)

datfmt(*iso)

timfmt(*iso)

And contrary to the example above, you don't need the dftactgrp(*no) if there is at least one option for ACTGRP, BNDDIR, or STGMDL, all of which require the dftactgrp to be *no. See how much time you're saving with /free?

And That's It . . . For Now

And that's all the time we have, folks. But stay tuned for next month and "Free-Form: The Gift Continues," where we'll talk about file control statements and other stuff. In the meantime, if you want more info on this topic, you can go to the following links. Or you can just pour yourself a glass of wine and settle back and wait.  

• RPG Café
• RPG ILE Reference—Check out the "What's New" section.