So far, we have hacked through basic /Free structure and the control statements that can be used to tame it and bend it to our will.
Editor's Note: This article is excerpted from chapter 6 of 21st Century RPG: /Free, ILE, and MVC, by David Shirey.
But what about files? So far, we have not really talked about them. How cruelly unfair, as files are at the heart of everything we do. But that is about to change.
As we shall see, most of the changes are to do with RPG I/O, not the way embedded SQL is used, but we will talk about that briefly also. SQL in full is definitely another topic for another day and has very little to do with /Free per se.
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;
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.
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:
Then, in the /Free portion of the program, we set the values of the KeyRec fields, then issue the opcode.
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 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.
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:
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érie” 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.
If all we need is a write, like when we write a display file header record, then WRITE works fine.
Finally, we have the display operator, which lets you put in free-form verbiage to show up on the screen.
The DSPLY can show complex statements through the use of parentheses and quote marks to separate out the various components.
/Free does not support the old HI, EQ, LO indicator scheme, so you can’t use indicators to check the results of your I/O. Yes, let’s all stand very solemnly and wave goodbye to the indicators as they drive out of sight. OK, cue the music, and let’s get this party started.
Or maybe you don’t feel that way. Maybe you liked using them. In which case, I am deeply and sincerely sorry for your loss. Hey, is that beer cold?
To do I/O checking in /Free, you need to rely on the built-in functions. Namely %Found for CHAIN and %EOF for SETLL, and so on. To set a “not” condition, simply code it as NOT (%Found), for example. (And yes, you are right, you could use this same technique if you are doing positional RPG.)
Remember, if you don’t specify a file ID with the %EOF/%FOUND, the system will look at the last record read. To avoid that, or even just to provide additional clarity, you can include the file ID in the BIF. Either of the following ways works.
I am assuming that you already know how to use %EOF and %FOUND, but there are some other error BIFs that might come in handy. Remember, these BIFs are not part of /Free per se. They are part of RPG and can be used in fixed format as well. But you really need them in /Free.
To get this to activate, you need to use the “e” extender on your CHAIN or READ: CHAIN(e), for example.
It functions like the LO indicator in fixed format (returning a 0 for good read and a 1 for not so good) and is the kind of thing you want to use if you have an error-handling routine that you can call. Although maybe I need to restate that: if you use %ERROR, have error-handling logic to take advantage of it. The error branch will be executed if some sort of error is detected.
This is used with the SETLL opcode to see if we found a record whose key equals the key we are pointing at.
It can be used with multiple key field keys, and also with a partial key.
If the value returned is 0, then it means that no records were found for whatever key (full or partial) you used. If the value is 1, then you got a hit. %EQUAL can help eliminate the need to do an actual read and check the file field against some other field to see if anything’s out there. You know, if you were just doing a CHAIN to verify the record exists, you could instead do a SETLL and check the value of %EQUAL. It’s less overhead than a CHAIN, which actually retrieves the data field by field.
An IF %EQUAL branch would be triggered by a hit on the key value.
So, What About SQL?
Before we go on, we need to say just a word about SQL since so many people are using it as their I/O tool of choice.
The good news is that you can use SQL in /Free. No problem.
There is no new functionality per se in that, so I am not going to go through it (that would be a completely different chapter altogether). But there are some changes in the format.
Most of it involves what you don’t need to do. For example, let’s take a very simple positional example.
To do this in /Free, simply remove the C, the /, and the +. Then stick a semicolon (;) at the end—the very end, that is. What you end up with is this. I have included the /Free just to show that the Exec must start in position 8.
And that is it. No end clause is available. I sort of wish there was, but there isn’t one so, I will just go on with my life.
Everything else about embedded SQL remains the same. The source member type is still SQLRPGLE. You still will have the SQL communications data structure automatically included in your SQLRPGLE program, and you still use a colon (:) to denote host variables in your SQL statement.
What Ya Shoulda Learned
So, everybody cool?
If you already know /Free, then this stuff should be no big deal. And even if you don’t know /Free, this stuff should be pretty basic.
In this episode we learned about:
- How to structure our keys given the fact that the KLIST/KFLD are not supported
- How to selectively update only some fields on an UPDATE without using O-specs
- How the DELETE function differs from the way it acted in positional RPG
- How to do other types of I/O statements beyond the SETLL/READ/CHAIN
- How to check for errors or other I/O conditions given the fact that the indicator error structure is not supported in /Free
- In addition, we looked at how SQL is handled in /Free.
What’s important is that you now have enough knowledge to be able to code 75 percent of the stuff that you need to do in /Free, 85 percent if you are good at faking it. Hell fire, I’ve done lots of stuff in other languages knowing a lot less than that. You’re golden!
So settle back and relax. You’re almost 3 percent of the way to being an expert in /Free-ILE-MVC.