You are currently on IBM Systems Media’s archival website. Click here to view our new website.

IBM i > DEVELOPER > RPG

Surprises in the New Free Format RPG


If you’re an RPGer, you’ve undoubtedly heard about the new completely free-format RPG language support delivered last year with the TR7 announcement for IBM i 7.1. We’ve written about it in IBM i EXTRA and blogged about it. Joe Pluta has also covered aspects of it, not to mention a lot of coverage at various conferences, webcasts, IBM’s developerWorks site and many other places. If you haven’t yet explored this great new RPG syntax, we’ll leave you to catch up using one or more of those links before you read this.

In this article, we thought we’d skip the basics and instead highlight a few things that may catch a few RPGers by surprise in the new free form language. For the most part, these are happy surprises—but a few are in the “gotcha” category. Many have been covered in some of the articles mentioned, but we haven’t seen a consolidated list of these little goodies anywhere.

Mix and Match

Unlike the pre-6.1 free-format logic capability, the new support allows developers to freely mix free-format syntax and fixed-format syntax without the need of any /Free and /End-Free directives. Hopefully most of you will be doing all your new code (and/or converting your existing code) to use only the new free-format syntax. But if for some reason there’s some nasty piece of code that’s just too cumbersome to move to free-format syntax, at least it won't inhibit you from using free form elsewhere in the program.

Another opportunity to “mix things up” a little comes with the capability to freely mix file declarations (formerly F specs) and data declarations (formerly D specs). Some of you may wonder why we’d want to do such a thing. We’re certainly not advocating the random interspersing of data and file declarations. However, there are some cases where such a mixture makes a lot of sense. For example, declaring the line counter right next to the printer file that uses it. Declaring the data structure(s) that will be used as the target for READs or CHAINs next to the files that use them also makes sense to us. We’re sure over time we’ll begin to discover some other valuable ways to use this mixing capability.

Gotta Love Those Defaults!

Sure, coding your F and D specs in free format is nice. It’s great to stop worrying about all the esoteric column/code combinations for the F spec options. You might still choose to align your declarations in columns, but they would be of your own choosing and done for esthetic reasons. But are there other benefits of the new support? Yes—the defaults! They can save us a lot of time and code.

On the File declaration, for example, as soon as you declare device type (Disk, Printer, Workstn, etc.) the defaults for usage have intelligent values: *Output for Printer, *Input and *Output for Workstn and *Input for Disk. So in many cases, we won’t need to code the usage at all. For that matter, even the device type will default to Disk if you don’t specify it.

File usage also has sensible defaults. For example Usage(*Update) implies *Input as well and Usage(*Delete) implies both *Input and *Update. But don’t be tripped up by the fact that the reverse is not true—*Update does not imply *Delete. So if you want update and delete capability, you must specify *Delete or both. Note also that *Output replaces the use of the A for record addition in the old spec.

Since only full procedural files are supported in free form, we don’t need to concern ourselves with where or how to specify that. And since virtually all our files are now externally described, *Ext is assumed for all file types. Program described files can be specified by adding the record length as a parameter to the device type, as in Printer(132))

So if you’re using an externally described non-keyed database file for input only, the following declarations all have the same effect:

  Dcl-F  Orders; 
  Dcl-F  Orders Disk; 
  Dcl-F  Orders Disk(*Ext) Usage(*Input); 

Even the options that still need to be coded are at least readable and relatively easy to remember, such as the Keyed parameter or Usage(*Delete).

One default is missing from the fixed format world, however. You must now specify a data type on a data declaration—you cannot leave the entry blank (unless using LIKE, of course). This makes sense since the length and decimal places columns (which determined whether the default data type was A, P or S before) are now parameters to the data type keyword itself. But the tradeoff for losing data type defaults, a bad idea anyway, is that we no longer have to code 0 decimal positions for numeric data types. So the following definitions are equivalent:

    Dcl-s  TotalQty  Packed(11 : 0);
    Dcl-s  TotalQty  Packed(11);

Another nice default arises on PR declarations. We no longer need to specify the program name (nor remember that it must be in uppercase!) with EXTPGM. It will default to a program with the same name as the prototype—in all uppercase, of course.

Even the new H spec replacement gets a nice new default. If you have ILE-related keywords specified, such as BndDir (Binding Directory) or ActGrp (Activation Group), you are no longer required to specify DftActGrp(*No)

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters