Midrange Programmer

In the last two issues of Midrange Programmer, I discussed the load-all and self-extending subfiles respectively. Depending on the subfile requirement, one of those techniques might be the perfect the solution. However, each has its limitations, both for the programmer and for the user. In this third, and final, article on subfile types, I am going to talk about page-at-a-time subfiles, which, as you'll see, affords the programmer extreme power and provides users with more flexibility. Come take a peek.

The theory behind the page-at-a-time subfile is that you never have more than one page's worth of data in your subfile at one time. The primary advantage of this type of subfile is that you aren't restricted to the 9,999 record limit that the load-all and self-extending subfiles are. Since the subfile is cleared and reloaded with each page key hit (up or down), you can page through an infinite amount of records. I create a second advantage by adding a position-to field. Since you reload the subfile with each page key pressed, you now can page up from the beginning of a subfile list (as long as it's not the beginning of your data file). With the self-extending subfile, if you used the position-to field, that became the new top of your list. The only way to get previous data was to use the position-to field again. With the page-at-a-time subfile, when you use the position-to field, you can page-up from the top of the list to get to previous data. That's because your program, not OS/400, will handle paging up and down. This type of subfile offers the most flexibility to the user, but it also requires the most code and can be the most expensive as far a performance is concerned.

I have included the DDS and RPG for the page-at-time technique. The data files used in this example are the same as in my two previous articles so I did not include them here. Taking a look at the DDS, PageAtATimeDF, for our page-at-a-time subfile, you will notice only two changes from that of a self-extending subfile. The first one is that the SFLPAG and SFLSIZ are the same. This means that your subfile will never contain more than one page of data. If you attempt to load past the amount specified in SFLSIZ, you would get an error -- so don't do that. The second change from the self-extending subfile is that I have added the ROLLDOWN keyword. This tells OS/400 that your RPG program will now handle the backward paging and since the ROLLUP keyword tells OS/400 that the program will handle the forward paging, then you can probably guess that your program will now handle all the paging tasks.

As you can see, the RPG, PageAtATimeRG, is now a little more complex, but still not too horribly complicated. In the D-specs, I have added a couple of stand-alone fields, SVLNAM and SVFNAM. I will use these fields to store the first name and the last name of the first subfile record. Since these fields make up the key to the database I am using, I will use them when the user wants to page backward or upward through the data. During the SFLBLD routine, when the subfile relative record number (RRN1) is equal to 1, I move DBLNAM to SVLNAM and move DBFNAM to SVFNAM. That sets those fields for later use. You will also notice that I added a ROLLDN constant. The last D-spec you see is also new and will also be used during the page-up process. The main routine of this program resembles what you've seen before, with the exception of the page-up processing brought upon by adding the ROLLDOWN keyword in the DDS. Let's look at the WHEN clause for a moment. When the user presses the page up key and the subfile has been displayed (indicator 32 is off), the GOBACK subroutine is executed. This subroutine is used for nothing other than setting the pointer correctly in the data file used for loading the subfile. I use the first record in my subfile to set lower limits (SETLL) in my data file, SFL001LF. I perform a DO loop that will read previous records in the SFL001LF up to one greater than the SFLPAG parameter. If I hit the beginning of the data file before my loop is finished, I set lower limits with *LOVAL to position the pointer to the top of the file and I get out of the loop. So by the time the loop has completed, my data file pointer will be positioned at the top of the file or be positioned at some point in the file as determined by what is contained in SAVKEY and SFLPAG_PLUS_1. After the GOBACK subroutine is executed, I clear the subfile and load a new page based on where I left off in the GOBACK subroutine. Now the user can page up or down from anywhere in the subfile, with the only limits being the beginning and end of the data file. This removes the 9,999 record limit.

You may remember from the self-extending example that there was a position-to field that allowed the user to quickly jump to a specific place in the data file, as opposed to using the page keys multiple times. Well, there's no difference in the way that the position-to logic is coded in a page-at-a-time subfile, but there is quite a difference in the way that it reacts. In a self-extending subfile, when you use the position-to, that entry becomes the new top, or the beginning, of your subfile. You are not able to page backward, because OS/400 handles that for you. With a page-at-a-time subfile, the position-to field still allows you to quickly jump to somewhere else in the data file, but once you are at this new spot, you are still able to page backward in the subfile, as long as you're not at the beginning of the data file. You are able to do this because your program, not OS/400, handles the paging tasks. This technique allows the user to be more precise in his decision about where to position to, because he knows he can easily page backward. For example, if you know the name you are searching for begins with an "s," and you know it's toward the end of the "s" names, instead of positioning to "s" and paging forward until you find the name, you could position to "t" and page backward. You can't do that with self-extending subfiles.

When I am unsure of the number of records I am going to load, or I think my data will grow, or I simply know that the number of potential records exceeds 9,999, I use the page-at-a-time subfile. By loading one page at a time, you are not limited by the number of records. This type of subfile is the most CPU-intensive because the scrolling is all handled by the program; therefore, each time the user scrolls through the data, the program has to go out to disk to get that data. However if there are tens, hundreds, even millions of potential records in your data file, this type of subfile (with position-to capabilities) is the way to go. I also use page-at-a-time subfiles when I want to add user flexibility to my application. As a programmer, you have more control over the subfile with page-at-a-time processing, and this can be beneficial.

These past few articles on subfiles have been a nice journey into the past, and, based on the responses, they are well-needed additions to the newsletter. Now you have at your disposal a subfile type for every occasion. Whether the data has very few records, many records, potential growth, or certain stagnation, you can rest easy, knowing that you have the proper subfile sword to wield at the project.