Midrange Programmer--Back to Basics: Data Entry Subfiles

In my last article, I showed you how to write a master file maintenance application using subfiles. This technique works well for those files that are not frequently maintained. But what about those that are? What about heads-down data entry? Can subfiles help us out there, too? The answer is yes. In fact, they are perfect for heads-down applications. Come learn how to write an application or two that will be able to keep up with the swiftest of data-entry personnel.

First let's concentrate on input only. I once had project to give the user a separate screen to add new data to the data file. Without much subfile knowledge, and not being willing to do a little research first (I must have been under a ridiculous deadline), I dug right in. I created a load-all subfile with about 50 records. In the subfile load routine in my RPG program, I cleared the subfile, using the SFLCLR keyword, and then performed a "do" loop 50 times and wrote empty records into the subfile. To retrieve the records from the subfile, I then chained to all 50, looking for non-blank records to write to my data file. This approach worked, but it had some flaws. What if the user only entered one record? I still checked all 50. I could have checked for the first empty subfile and stopped there. But what if the user skipped a subfile record for some reason during data entry? Those entries after the blank entry would have been missed.

You were introduced to the read changed records operation (READC) in the last article, so you've probably figured out that I should have used it to read my changed records, instead of chaining to each subfile entry. But there's more. I also could have used a different technique to write the 50, non-blank records to my subfile without a do loop, in my RPG. That way is to use the SFLINZ keyword in your DDS instead of SFLCLR. SFLINZ works just like the SFLCLR keyword, except that instead of an empty subfile, which is the result when you use SFLCLR, SFLINZ provides you with a subfile with the number of records specified in your SFLSIZ keyword. The fields, depending on their type, will all be initialized to zeros or blanks.

This subfile is very easy to code. The DDS, DTAENTDF, is as simple as a typical load-all subfile. The RPG, DTAENTRG, is also very simple. There is no load routine to get the initialized records, only a routine to read the changed records, using the READC operation, and to process those changes. A keyword you can use along with the SFLINZ keyword is the subfile record not active (SFLRNA) keyword. This keyword works in conjunction with the SFLINZ keyword to make the initialized records non-active. A subfile can contain non-active subfile records. In fact, the only way you can make subfile records inactive is by specifying SFLRNA with the SFLINZ keyword. Now let's look at the three ways to make subfile records active:

By specifying SFLRNA in my DDS, my 50 initialized records will be inactive. This will save CPU processing time, because the READC operation will only look for changes in active records. So out of my 50 initialized records, if I only make changes in one of them, the READC operation is only going to check that one record, because it is the only active record in the subfile. The READC is smart enough to process all the changed records, even if there are inactive records between them. This is not the case with the CHAIN operation, because although it can work with inactive subfiles, it doesn't perform well when there are both active and inactive subfile records in a subfile. It is therefore in your best interest to use the READC operation, even if you use SFLRNA with SFLINZ. The combination ensures that your program will process all the changed records while reading the minimum amount of subfile records.

Using the subfile cursor progression (SFLCSRPRG) keyword can also aid the data-entry professional. I use this field when I want to control which field the cursor goes to when the tab key or field exit key is pressed. The normal progression of the cursor is from left to right across the screen, moving to all input capable fields on one line before going the first field on line 2. Let's say the normal progression is not how the user wants to enter the data. What if the user wants to enter all the last names first and then the first names? The SFLCSRPRG lets you accomplish this. All you do is place the SFLCSRPRG keyword under the field you want the cursor to progress to and away you go. It is not activated until the cursor enters the field on which you defined SFLCSRPRG, so in my program the cursor would start out on first name, the user could either enter the first name or move to last name, using the tab or field exit key. Once there, the user would enter a last name, hit tab or field exit, and the cursor would jump down to the next column in the last name field. This way, the user could enter all the last names before entering any first names, without keying extra keystrokes to make it happen.

If you had more fields in the subfile but wanted to fill each column first before moving to the next column, you could place SFLCSRPRG on every field in the subfile. This would cause your cursor to move top to bottom, instead of left to right, for all fields. Simply remove the SFLCSRPRG keyword if you want your subfile to process in a more traditional fashion. I added it to show you how it works.

With this subfile, someone who knows his way around a keyboard could add records to a data file in record speed. Heck, I even appear fast using this method.

I've just showed you a simple program to allow you to write new records to a data file, but what if you wanted to update and delete records using this technique? Can you do that? Of course you can. Check out DDS DTAUPDDF and RPG DTAUPDRG. Notice in the DDS that I define all my fields as type B, which means input/output. I also add a hidden field to hold the identification number field. This is the key to the physical file that I will use to delete records. If the user blanks out a subfile record, my program will chain to the physical file using the hidden field and delete that record from the file. Another thing to note is that this will be a load-all subfile program because I want blank lines to follow the current data in the file. Because I am going to allow blank subfile entries for adding data, I am going to use SFLINZ instead of SFLCLR. This will give me the desired lines at the end of my subfile, assuming that I have made SFLSIZ large enough. To offset making SFLSIZ too large, I will use SFLRNA to make the blank subfile records inactive. They will only be made active, and therefore dealt with by the CPU, by one of the three ways mentioned earlier in this article.

As for the RPG, I turn on indicator 31 to initialize 50 inactive records and load all the data from my data file. Since the records are inactive, I will use the WRITE operation to load data into them. If the subfile records were active, I would have to CHAIN to the subfile and UPDATE it with the information from the data file.

Once I am finished loading the subfile with data records and allowing it to be displayed by setting the appropriate indicator, I display it to the user. If the user pages down through the subfile, he will eventually come to the end of the data and the beginning of the blank lines. To modify a record, he simply keys over the data in the subfile record. To delete a record, he blanks out the data on the subfile record (I have made it so he only has to blank out the last name). To add a record, he keys data in one of the blank lines.

Once the Enter key is pressed, the program processes the changed records, in the PRCSFL subroutine, by using a READC loop, the hidden field, and the data entered in the subfile, to analyze what to do with the record. If the subfile (or the last name, in my case) is empty but there is something in the hidden field, that record is a candidate for delete, because it holds the hidden key. If there is data in the subfile but nothing in the hidden field, that's an insert. And finally, if READC detects a changed record with data in the record and something in the hidden field, that record is a modification to an existing record.

If this program will be used more for adding records than for modifying or deleting records, there is a very fast method to get to the first empty record in the subfile. That is to use the SFLRCDNBR keyword, but with a slight twist. The SFLRCDNBR keyword is used to display the page of the current relative record number. If the relative record number is 16 and record 16 is on the second page of the subfile, the second page will be displayed when the EXFMT operation is used in your program.

The twist to accomplish getting to the blank records is to add the parameter (CURSOR) to the SFLRCDNBR keyword, as I've done in the DDS. What this does is display the page where the current relative record number exists, but it also places the cursor on the exact line that matches the relative record number. So in your load-all routine, if you add 1 to your relative record number, instead of initializing it to 1after all the data has been loaded from the data file, the program will display the first page with empty subfile records and place the cursor at the first empty subfile line. I have done this in the program included with this article. If you choose to display the subfile on the first page, simply change the RPG to initialize the relative record number to 1 once the subfile is loaded.

Before using this technique to modify or delete records from a data file, there are a couple of things to take into consideration. First, when deleting records in this fashion, you are providing no confirmation to the user. A record could be inadvertently cleared and subsequently deleted without the user ever knowing it. Also, updating and record locking becomes a bit more crucial using this technique. In my maintenance program in the last article, each time a record is displayed for update, it is retrieved from the data file. The record is easily locked while the user remains on the update screen. In the new example, all the data is loaded at the beginning of the program. The user can change any record as he scrolls through the data. In the meantime, the data may have changed between the time it was added to your subfile and when you finally modify it in your program. If other users are able to get into this program at the same time, they may not always have the most current changes, and they may make changes themselves, thus wiping out your changes. You can certainly allocate the files to one use of the program, and solve the problem. But the fact remains that data integrity must be compared with speed of entry each time you design a file maintenance subfile program. You may want to use this technique for data entry only and leave the maintenance to something like you saw in the last article. The choice is yours.