Learn to work with keys and output opcodes, two important options for handling files in your /Free ILE RPG programs

Editor’s Note: This article is excerpted from chapter 6 of 21st Century RPG: /Free, ILE, and MVC, by David Shirey.

Some things in /Free have not changed from fixed format, like the opcode names for the database I/O: READ, READE, READP, READPE, CHAIN, SETLL, SETGT, UPDATE, WRITE, and DELETE.

And you still have that weird thing where READ, CHAIN, and SETLL can use the file ID in the statement while UPDATE, WRITE, and DELETE must use the record format.

Of course, the basic syntax is different (from positional RPG), with the order being more English language and the semicolon at the end. And the indicators that show the outcome of the I/O operation are not supported. But you have some additional options with keys that I really like. Shall we?

Working with Keys

Speaking of keys, remember how in the olden days you had to code up C-specs with the KLIST and KFLD elements? Well, that’s not supported in /Free. Can I get an Amen? Neither do you have to set up key definitions in either D- or C-specs. Instead, you may simply list the keys as arguments separated by colons (not semicolons) in the I/O statement, and the system does the rest.

CHAIN (keyfld1:keyfld2:keyfld3) FileID;

or

SETLL (keyfld1:keyfld2:keyfld3) FileID;

Where does /Free get the info to know what the proper keys are, how long they are, what data type, and so on? From the files that are specified in the F-spec, of course, with help from a little compiler magic that is what makes /Free free. I like this. I like seeing the list of keys that we are using right in the CHAIN/SETLL: it’s very self-documenting.

And the keyfld fields that are specified in the I/O statement do not have to be the actual ones from the file you are reading. That is, the name used in the CHAIN/SETLL does not have to be the name of the actual key field in the file. It can be any field name as long as it currently holds the value you want to key by. Naturally, the non-file field does have to be the same size and type as the actual key field.

So, if you are picking up a field from a screen, say a product number, and want to see if it is valid, you could use the field from the screen right in the CHAIN or SETLL. No time wasted moving it to the actual key field name.

It could even be a BIF statement, like %CHAR(num_field). Don’t forget that’s just a variable like any other variable except that it will be transformed before it is used. Sort of like a caterpillar becoming a butterfly, which is then eaten by a bat.

Technically, if there is only one field in the key, then you don’t need to put it in parenthesis, but I think it’s a good way to keep things organized. Besides, what self-respecting file has only one key field? Sheesh!

Of course, if you do have a large number of key fields in the file, then the list could become pretty long and unwieldy. But since this is /Free, all you do is just stack them up vertically and keep on going.

CHAIN (key-fld1:

       key-fld2:

       key-fld3:

       key-fld4:

       key-fld5:

       key-fld6) FileID;

Another Way to Deal with Keys

Now, in fairness, I have to tell you there is another option for handling keys. I don’t care for it, but that is a personal preference, so I will still cover how to use it. It’s a perfectly fine method, if you like doing things that way. I guess it’s up to you. Takes all kinds, don’t ya know.

The other method starts with a D-spec that sets up the key format using the LikeRec keyword and the record format of the file:

D KeyRec       DS     LikeRec('Recfmt':*key)

Then, in the /Free portion of the program, we set the values of the KeyRec fields, then issue the opcode.

KeyRec.field1 = Data1;

KeyRec.field2 = Data2;

KeyRec.field3 = Data3;

KeyRec.field4 = Data4;

KeyRec.field5 = Data5;

KeyRec.field6 = Data6;

Chain %kds(KeyRec)FileA;

It just seems like a lot of bother to me. But use whatever works best for you. You know what they say: “Even folks what prefer a paddle can make use of water-soaked branch from time to time.” And I agree.

Output Opcodes in /Free

Of course, you can also do WRITE, UPDATE, and DELETE in /Free.

WRITE

WRITE is pretty much what it was in positional RPG. Actually, it’s exactly the same, if you ask me.

You specify the file record format, not the file ID, and that’s that. It writes the entire record out at one time.

Write record-format;

UPDATE

UPDATE is also pretty much the same, using the record name versus the file ID.

The one difference is that in positional RPG, you can update only some fields in a record. To do this, you need to use the EXCEPT operator and set up O-specs to indicate what fields are being changed.

You can do the same thing in /Free (a partial update) but much more directly by using the %fields addition:

UPDATE record-format %fields(field1:

                             field2:

                             field3:

                            field4);

DELETE

The DELETE also operates on the record name. In positional RPG, you do not have to do a CHAIN first, but if you don’t, it will delete the last record read.

In /Free, you now have the option of putting a key value in the DELETE statement, which makes that read unnecessary:

Delete (keyfld1:keyfld2:keyfld3) file-record;

Workstation-Type I/O Statements

Although green screen is not anyone’s “le petit chéri” for development anymore, it still does appear. And so, we need to know what opcodes we can use for the display files they are built on.

EXFMT (Write, then Read)

This opcode is used for workstation input and output. Generally, it is used when we need to do both a write and a read in sequence, as when we are dealing with a subfile.

It does a write to the display file of whatever data has been moved to that file record, then reads the next display record in the sequence.

EXFMT display-record-name;

WRITE

If all we need is a write, like when we write a display file header record, then WRITE works fine.

WRITE display-record-name;

DSPLY

Finally, we have the display operator, which lets you put in free-form verbiage to show up on the screen.

DSPLY verbiage;

The DSPLY can show complex statements through the use of parentheses and quote marks to separate out the various components.