RPG took a great leap forward when free-form C-specs were introduced. Now, with a PTF on V7.1, you can extend that to do free-form H-, F-, D-, and prototype-oriented specs. Want to know more about it?

In our last exciting episode, we looked at free-form in RPG in general and started to go through the new additions for the V7.1 PTF by looking at the replacements for H-specs (option control statements). Now it's time to move on to the other positional specs and their free-form control statements counterparts.

File Control Statements: Basic Format

Let's start with the F-specs. Like all control statements, the file control statement starts with the statement keyword (dcl-f), followed by the name of the file, followed by whatever other keywords might be required. For example:

dcl-f MSPMP100 DISK;

Of course being free-form, you can write it in sentence format like this or put a few spaces in there so it's easier to read, such as this:

dcl-f       MSPMP100       DISK;

DCL-F     pspsp100         DISK;

Or however you want it to look.

Some Other Things You Should Know

What types of files can you define here? Full procedural and output files only. You cannot define tables, record address files, or cycle files with this statement. So what do you do if you just can't live without one of those files? Simple: fall back on the F-spec. Remember from last month's article, you can use either the F-spec or the file control statements and even mix them together with no problem. The same is true of other specs and control statements including C-specs and /free RPG code.

How long can the name be? You can use names longer than 10 digits as long as you use the EXTFILE keyword with a value of *EXTDESC with it. Then the EXTDESC keyword will contain the 10-digit name of the file. And if you were a fan of using ellipses here, can't do that anymore. It should also be noted that you can't use any of George Carlin's "Seven Words You Can't Say on Television" in the file name, although most people under 35 use them constantly in casual conversation.

dcl-f       Product_Master_File   Disk EXTFILE(*EXTDESC)

                                           EXTDESC('MSPMP100');

Is there some sort of order you need to list all of this stuff in (since it's not positional anymore)? Of course! What do you think we are, animals? You start with the "dcl-f" thingy. Then comes the file name. Then the first keyword you need to specify is either the device keyword (DISK, PRINTER, SEQ, SPECIAL, or WRKSTN) or the LIKEFILE keyword. After that, it's a free-for-all. And speaking of the device keyword, here's some more stuff.

The Device Keyword

If you don't key in this third element (dclf-f is first, and file name is second), the system will assume that it's DISK, but I really think that's RBFJ (Really Bad Form, Jack). It's a couple of lousy characters. Just key it in.

If the file is externally described, you can use the EXT value in parentheses with the device keyword: DISK(*EXT) or PRINTER(*EXT). But that value is the default, so here you can ignore it and I don't consider that RBFJ. I know, it's a judgment call, but it makes sense to me.

If we're dealing with a program file, then you specify the length of the record along with the file type: PRINTER(132).

Confused? Let's look at a couple of examples. The first is a printer file with a name longer than 10 digits.

dcl-f           year_end_report                 printer           oflind(overflow

                                                                  extdesc(‘XXXXX’)

                                                                  extfile(*extdesc);

Again, note that I have listed the three keywords in a vertical format, but that's not required, and there's no particular column that these have to start in (hey, this is free-form). But I like to list the keywords in a vertical format and so do most cool people. It's up to you, though. Just keep everything in columns 8 – 80 and you won't get any compiler errors.

One thing that should be re-mentioned here is that, because this is free-format, you need to end each statement with a semicolon. The question is, does this mean a semicolon on every line? The answer is no, just on the final line of the control statement. Remember, even though I like to put things in a vertical format, each dcl-f statement is a single statement.

The Keyed Keyword

Remember the K flag to indicate a file was keyed? That has been replaced by the Keyed keyword.

For an externally described file, there is no value attached to the keyword.

dcl-f     MSPMP100     DISK     Keyed;

For a program described file, you can indicate a value of *CHAR:len, where len is the length of the key (duh). Unfortunately, I guess, only *CHAR keys are supported right now. But then again, I don't dig program described files. Why not define it externally? Are you ashamed of it? Whatever, in the example below, we have a program defined file with a length of 120 and an 8-character key.

dcl-f     Prog_File     Disk(120)     Keyed(*CHAR:8);

What if you have a packed key? Well, then you make it an externally described file. Or, if you insist, either through willfulness or the same type of behavior that has been strongly linked to juvenile delinquency and drug abuse, you can define the key as *CHAR in your file control statement (almost said "spec") and then lay that out in a data structure like so:

dcl-f prog_file   DISK(519) Keyed(*CHAR:7); //you don’t put ds

                                             //name in the file

                                             //in file control

                                             //statement.

dcl-ds    key     len(7) qualified;

         order_number packed(12);

end-ds;

And the nice thing about this is that it shows how you can mix dcl-f statements and dcl-ds statements so they're next to each other—that is, the end-ds statement could be followed by another dcl-f.

TheUsage Keyword

The USAGE keyword replaces the file type (I, O, U) and the file addition (A) flags in the F-spec, a la USAGE(*INPUT).

You can specify more than one usage, like *UPDATE and *OUTPUT or *INPUT and *OUTPUT. If listing more than one usage value, use a colon to separate them, like so:

USAGE(*UPDATE:*DELETE.)

In F-specs, a U can be update and/or delete, but in free-format, *DELETE is its own man and must be specified if you want to do a delete.

The default for DISK is INPUT, for PRINTER is OUTPUT, for WRKSTN is (*INPUT:*OUTPUT), and for SEQ and SPECIAL is *INPUT. But you know how I feel about defaults. RBFJ.

Of course, the old hierarchy still holds. So *UPDATE implies *INPUT, and *DELETE implies *UPDATE and *INPUT. We aren't changing everything. All we're doing is making things more visible, more obvious. And that's important if you're teaching somebody who wasn't born in a 36 shop how to use RPG. And isn't that what we want? For more people to know RPG?

Fortunately, most keywords currently in use in F-specs can still be used for file control statements. This includes things like the RENAME or the PREFIX. But for a full view of what's still supported, you should check out the RPG Programming Reference Guide. What you need to look at here are the lines with a vertical bar (|) next to them. This shows things that are new in the 7.1 PTF and covers the new free-form control statement details.

If/Then/Else in a Control Statement

I know. This is really weird. But with this 7.1 PTF you can actually imbed If/Then/Else commands within the file control or other statements.

Now I know what you're thinking. Why? Right? Well, maybe you want to vary the keywords that are associated with the file. Or maybe you just like to make things very complicated. Lots of people like to do that. To be honest, it doesn't really matter why you would want to do this. What's important is you can. Actually, you're more likely to do this kind of thing with data structure control statements, which we'll look at more closely next month when we discuss that. Oops. I gave away the surprise ending. Pretend you didn't hear that.

The point is, you can if you need to. And sometimes it might be helpful to be able to assign file control statement keywords based on some external thingy. Like suppose you had a flag that was set based on a user profile value and it indicated a level of trust: either an input only or update state. You could control that with code like this built right into where your F-specs would go now. And don't confuse the slash (/) in front of the IF with the double slash (//) that indicates a comment. These are not comments:

/IF flag1 = 'I';

dcl-f product_master Usage(*input) Keyed;

/ELSE;

/IF flag1 = 'U';

dcl-f       product_master   Usage(*Update)                

                             Keyed;

/ENDIF;

/ENDIF;

Summary

So admit it. That was fun. Right? The next step will be to look at the final specs being replaced by the control statements: data structure and prototyping oriented structures. Stand by for next month. And until then, if you're on 7.1 and have the PTF for these enhancements, give them a try. And if you don't, then push for an upgrade! Remember: being current is not a penalty; it's a reward.