The Geezer’s Guide to Free-Form RPG, Part 5: File Definitions

While the changes in data definition introduced by the new free-form RPG support are great, I have to admit that it was probably the free-form file specifications that raised the biggest cheer from me. Let me tell you why.

I have always hated F-specs. Those nasty little single column codes drove me crazy. I could never remember what went where. I know I’m not the only one. All of the programmers we have taught RPG to over the last few years have also had similar problems coming to grips with with F-specs.

I am reminded of this almost every time I dive into coding, since F-specs remained as the only thing I ever needed the prompter for once I started to use RDi for all my development work. Now, for the first time ever, I am coding file definitions without prompting and without referencing the manual.

Happy, happy, happy!

So, let’s get into some details.

Basic Syntax

As with all the new declarations, file definitions begin with the characters “dcl-” for files, followed by “f”. It might have been nice to be able to spell out “file” as an alternative, but I’m happy enough with just the “f”.

The name of the file follows and here we encounter our first new feature. BIG file names! Or perhaps, to be more precise, the option to use meaningful file names. In the past we were stuck with using a traditional 10-character system name for our files, but no such limit applies in the new RPG. I really like this because it has always bothered me that determining the function of a file in a program invariably requires the use of some secret decoder ring. This is often worse in the case of print files where, for example, a monthly sales summary report might have a highly meaningful name such as SLSRPT0055. How much better it is to be able to use a meaningful file name. Of course it would be even nicer if we could also use meaningful record names, or indeed use the file name for all I/O operations on single format files, but I digress.

The downside is that you need to specify both the EXTFILE and EXTDESC keywords as you can see in the example below. I can’t help wishing that the compiler had not been as strict about this and had simply allowed EXTDESC and provided EXTFILE(*EXTDESC) as the default whenever it was used. Perhaps we’ll see this in the future.

Here’s the original fixed form version of a printer file definition:

 FSLSRPT0055O    E             Printer OflInd(pageFull)

This is a straightforward translation:

  dcl-f SLSRPT0055 Printer OflInd(pageFull);

And this uses the new long name support:

  dcl-f MthSalesSummary Printer ExtDesc('SLSRPT0055') 
                                ExtFile(*ExtDesc)
                                OflInd(pageFull);

The next entry following the name must be the device keyword, or alternatively LIKEFILE. If no device is specified then the compiler assumes a default of DISK.

Once the device has been specified then next come the device specific keywords. These are basically those that used to appear in the keyword area of the F-spec, and since these are basically unchanged I won’t deal with them here. There is, however, one new keyword, KEYED, which replaces the old “A” and “K” entries in the Record Address type field. The remaining single column entries, such as Limits Processing, are not supported in free-format. If you still need them then you must stick with a fixed format definition.

File Usage. . . At Long Last Sensible Defaults

As I noted in my first tip on this subject, one of the best parts of the new support is the use of sensible defaults.

No longer do we have to tell the compiler that files are externally described: it is the default! If you get nostalgic for the bad old days you can always add *EXT as a parameter to the device type keyword—i.e., DISK(*EXT)–but why bother? Nor do we have to specify that a printer file is used for output. Output is the default usage for printer files! In a similar fashion, the file usage (input, output, both) also defaults based on the device type.

To give you the full picture, here are the defaults for the basic file types: