“Subfiles in RPGIV” and Me
Subfile processing is an integral part of RPGIV data entry and data display. To be a real pro, you need to handle them properly. There are any number of ways to build and maintain them. Depending upon your level of expertise, you can do really sophisticated data processing tasks with subfiles. (Yes, I know that phrase data processing is so 1970’s.)
Dealing with them at my place of employment is an ongoing task. My two fellow programmers, though having much experience in programming, are relatively new to RPGIV. To help enhance their skills, one of them bought the excellent book by Kevin Vandever, “Subfiles in RPGIV”.
One of them was using it to help him build the first subfile program he had ever written from scratch. And wouldn’t you know, his techniques were different from mine! And the author had used my technique when he first started programming subfiles, but he had found a better one. Oh, my.
For the uninitiated, subfiles are a way to handle update and display of data files, by allowing you to display multiple instances of data in (usually) a columnar format, then treat each line as a separate data record. In RPGII, subfiles were not available; to process it, you had to plug your file data into arrays of information, each data field in an individual record linked by being the same array element in multiple arrays.
Anyway, the author recommends a technique that is clean and efficient. He uses the DDS keyword SFLNXTCHG to allow the programmer to flag for further processing data in a record that has been changed. The operating system keeps track of changes, and this allows the programmer to process only those subfile records that have been changed by the programmer. This is done by using the READC (Read Changed record) RPG opcode. Using SFLNXTCHG with an indicator allows the programmer to mark a line of data as “changed” when it processes the second time around. If one entered erroneous data in error, and the program would not accept it, the data would still be marked as “changed” and the record would be read the next time around by the READC opcode, even if the data entry person did not correct or change the data.
My approach, the way Mr. Vandever set aside, is to keep track of the number of records (entries) in the subfile. To process the subfile, I CHAIN to each subfile record by relative record number, whether it is changed or not, and process the data as needed. I can do this as many times as desired.
Why do I do it my way? Because I’m an ignorant so-and-so, I guess- or at least I was when I was learning many years ago how to program subfiles. I vaguely remember attempting to use READC to process only changed subfile records. However, I was not aware of the SFLNXTCHG keyword; and when I would read a subfile record and find an error, I couldn’t see how to tell the system to process the record the next time around. Suppose the screen had five subfile records displayed. I changed two records, and one of them was in error. Once I fixed the one in error and the program looped through with the READC opcode again, it would not pick up the correct one from the previous pass because it couldn’t tell it has been changed! When I saw an example of the CHAIN technique, I realized that it would always work, so I stuck with that technique.
So do I change now to the more efficient technique in the future? Wellll…. probably not. Being a creature of habit, for one thing; and the fact that changing my technique will not gain me all that much and would make the “read subfile” task more complex.
But what about all the unnecessary CHAIN operations, which on a large subfile mean an awful lot more subfile accesses than necessary? If you have read my blog from the start, you might remember when I told about a hissy fit I had when I worked on a program where a previous programmer read a detail data file by CHAIN instead of READ and increased the processing time by a factor of 10 – from 15 minutes to 2.5 hours.
I suppose that I have been corrupted by the greased lightning bottled in the latest machines. In my file cross-reference program, I load source files into subfiles so that you can drill down into the subfile and find out file characteristics, even view the data in the file by putting the cursor on a file name and clicking a function key. When I tell the system to display source, it can put 9,999 lines of source to the subfile in less than a second. Why sweat the difference in processing one record with READC versus, say, 12 when using CHAIN? In a large installation with hundreds of users on a slower machine, perhaps it would be a concern- but not now. My concerns about performance are pragmatic, not ideological. As I have said before (as a matter of fact, in that previous blog post I mentioned above), I don’t sweat over nanoseconds.
Also, at least with reference to my cross-reference program, using READC is irrelevant. I do not change the subfiles in any way. They are simply a jumping-off point for further processing. I use EXFMT (which means write the format, then accept input) to display them, but only to allow the input of a right-click or a command key or a search argument to use with a command key.
A minor quibble would also be that an edit that relied on READC would catch only errors that had been introduced by the current data entry operator. There is no way to guarantee that the data in the subfile is error-free when it is first displayed, especially if the data is also updated by other programs. If you edit every line, you can check for errors in all the data, including preexisting errors.
So my partners are free to use the new techniques, but I am not likely to choose to do so in the future.
May 15th, 2009 at 5:32 pm
I agree with you. I prefer to use CHAIN for each RRN instead of READC. If I use READC with SFLNXTCHG, I lose the ability to tell if the user did or didn’t make changes, because SFLNXTCHG will cause unchanged records to pop up as changed.
When I write subfile apps, I usually want to show the screen to the user after his keying is done, and only proceed to the next screen (or whatever) if the user has made no changes. I can’t detect that condition if I use SFLNXTCHG. The CHAIN technique is more versatile.
In 16 years of subfile programming, I’ve never had trouble with performance using CHAIN. Today, the thought of a performance problem is almost laughable. It’s only 9999 records, after all… on today’s computers, that’s nothing.
June 19th, 2009 at 2:36 am
ReadC, Chain. I see both points. Good discussion. Just glad folks are still talking about subfiles. Thanks for mentioning the book.
Kevin.
July 8th, 2009 at 11:31 pm
How do you “force” the current screen to get read as in this case.
I put roll down and roll up keys in the DDS.
I display screen 1 of the subfile and roll thru the subfile to EOF.
Then roll back. How come the program does not process the roll down key. The subfile maintains control for all the roll down keys. I want to do some processing on the screens as I am rolling back.
,
July 10th, 2009 at 7:32 pm
If I understand your question correctly, you have created a subfile that consists of one or more screens of data, then scrolled to the end of the subfile.
For the sake of discussion, let’s say you created a subfile of 48 records, consisting of 16 records per screen. When you roll back, you are in within the subfile. You can scroll back and forth within these three screens. The operating system itself, not the program, is in control of the roll keys. Assuming you have input capable fields, you can update the data within the subfile with either of the methods mentioned in my post. In this case, the roll keys will kick in when you scroll forward (roll up) at the end of the subfile.
If you are at the first screen, you can go no lower; you will probably get a keyboard error if you attempt to roll back.
I’m not sure I’ve answered your question. If I haven’t, let me know.