So far, we've covered free-format control statements and H control statements (Part 1), and file control statements (Part 2). What's left? Just data structure control statements, and the PI and PR control statements used for prototyping. So let's jump in.

D-Specs

By this time, if you've read the previous two installments, you know that things start not with a D in column 7 but with the data structure control keyword somewhere in columns 8–80.

dcl-ds

This will then be followed by the data structure name and whatever keywords might be required:

dcl-ds Product_rec likerec(PMP100);        

Or if you like to leave a bit of space, do this:

dcl-ds     Product_rec     likerec(PMP100);

You can define a number of things here, and each has a slightly different control statement keyword. But one thing that's true in all situations is that the ellipses that we can use in D-specs are not valid in data structure control statements.

Named Constants

The first things you can define are named constants. This is done with the dcl-c keyword, versus the dcl-ds keyword. Once the constant is defined, you can use it in your program. And I honestly don't know why I said that. Sort of stands to reason, doesn't it?

Below is a good example of how you use named constants and mix the file and data structure control statements. And it also shows how you don't necessarily need to have the file control statements first. Why would you do this? Well, it allows you to then refer to the file as the Product_Master elsewhere in your program rather than MSPMP100.

            dcl-c       Product_Master         'MSPMP100';

            dcl-f     product_master     output       printer 

                                                                             oflind(*overflow)

                                                                             extdesc(Product_Master)

                                                                            extfile(*extdesc);

Just an option. Not a rule.

Standalone Field

You can also define standalone fields. Start with dcl-ds, and end with a semicolon (;).

If you do name the data structure field, and most of the time you will, then that comes next.

If you decide to not name it, you can just use the symbol '*N'. Not sure why you would not want to name it, but I'm sure some people would think if the field were not very important, if it were just intermediary in nature, then maybe you shouldn't name it. I don't care for that, but I'm continually amazed by how many people don't check with me before doing stuff. Even important things like naming variables.

After the name (or *N), then we get the keywords. Are you beginning to see the pattern here?

The first keyword must be either LIKE or the data type and length. That is,

dcl-s name LIKE(other_name);

dcl-s order_number packed(6:0) inz(0);

dcl-s next_order_number LIKE(order_number: +1);

dcl-s next_order_number           Like(order_number: +1);

The end-ds is not used for LIKEDS or LIKEREC. You can code the data structure name on the END-DS for documentation purposes, and if there are no standalone fields, you can put the end-ds on the same line as the dcl-ds.

Overlay

This is a small point but an important one, and it deserves a section of it's own. Ready? Brace yourselves. The overlay keyword is now supported only in specific situations.

Specifically, you can only use it to overlay subfields. It cannot be used to overlay the entire data structure. Now remember; this is only when you're using the data structure control statements. And there's no support at all for the Overlay(ds:*next) because that means there's no set position—just put it after the last field in the data structure, so that's meaningless. Since you can intermix the new control statements with the old D-specs, you could still use the Overlay on the D-spec. Personally, I don't have a problem with saying goodbye to the big overlay. As far as I'm concerned, that's a holdover from the days when every bit of memory had to be weighed and measured. That's not the case today. Overlays help hide what's going on as you move from one field to another, and I'm not at all sorry to see them restricted. We tend to hold on to things long after they have outlived their real purpose. But that's just me.

Subfields

Technically, subfields should start with a dcl-subf, but it's required only if the name of the subfield is the same as a free-form op code, like write or eval.

If the subfields need to be positioned, use the POS(99) keyword to indicate where that subfield starts. It replaces the fixed-format from and to values.

And you know what I believe? If you have subfields, then you must include the end-ds.

PR and PI

As you probably know, the PR and PI structures are used—especially in /Free (but also in regular RPG)—along with the P-spec to support the CALLP prototyping call statement. Things for the PI and PR specs are done the same way as DS'es. And the end-pi/end-pr is required.

dcl-pr dws0176 extpgm;

      parm1 char(256);

      parm2 packed(10:3);   

end-pr;

dcl-pi          dws0170;

               parm1 char(256);

                parm2 packed(10:3);

end-pi;

On the PI, if there's no name for the group, you can use '*n' just as you can for data structures.

On the PR, the 'extpgm' keyword is optional, and if you don't code it, the compiler will default to using the name of the PR group as the program name being called. But this is only if the program name is 10 characters or less'"'".

Also on the PR group, if the program you're calling has a mixed-case name, you need to use the 'extproc' keyword, like so:

dcl-pr         EL3write          extproc('EL3write');

Or you could use the *dclcase to avoid retyping the name:

dcl-pr EL3write extproc(*dclcase);

This can sometimes help prevent typo errors if you have several programs you're calling that have similar names and you copy lines but forget to change the name in the extproc keyword. Or you can stop using mixed-case, weirdo names that you can easily screw up. Your choice.

Procedures

Finally, we get to the procedures syntax in free-format. In spec language, these are defined by a P-spec, but using the new free-form format, it starts with a dcl-proc with a procedure name and keywords and ends with the end-proc (the procedure name on the end-proc is optional).

dcl-proc        procedure-name    keywords;

end-proc        procedure-name;

Summary

It took a while, but I think we've worked our way through the free-form enhancements for 7.1   And that's a key thing to remember. These are enhancements that are only for 7.1. If you're not on 7.1, fahgettaboudit. It's only for the cool kids. Yep, it's just like in high school. The cool kids get everything. But if you're not on 7.1, then this should encourage you in that direction. Moving forward is always a good thing.