Yeah, I know. Subfiles have been around for over 20 years, and everyone who programs on the AS/400 should know how to implement them, right? Well, I find that just isn't the case. Some programmers are never exposed to subfiles or they code them so infrequently that they forget what they did. So I am going back to the basics in this article to provide you with a fundamental but practical application that employs multiple subfiles on a single screen.

There are two ways to display multiple subfiles on a screen. One is the over/under method, with one subfile on top of the other. That is the type I am going to explain in this article. The other method is to display subfiles side by side. This method is a little trickier to pull off because of the way a subfile occupies space on a screen. I will discuss side-by-side subfiles in a future article.

Let's take a look at the DDS for the over/under subfile technique. In this example, I am going to display two subfiles on a screen, but you can use the same technique to display up to 12 per screen. Once you understand the basic concepts, your only challenge in adding more subfiles is figuring where to put them; the technique is the same. It's pretty straightforward.

My header will simply display a title line in row 1, the name of the program, and the date and time. My first subfile control record will start on line 3 and will contain the column headings for my first, or top, subfile. Notice that this is a load-all subfile. In fact, I not only use the load-all technique in this example, but I use it in all of my multiple subfile applications. I'll explain more on this later.

So my first subfile will contain the first name, middle initial, and last name. Nothing earth shattering so far, right? Now look at the second subfile in the DDS. The subfile control format starts in line 13, with the subfile record format directly under it on line 14. In my example, the subfiles are identical. This is probably not what you would do in the real world, but for simplicity's sake I am displaying the same subfile two times on the same screen. Last, I define my function key format, FOOTER, to display the valid function keys available to the user. There you have the DDS. Two subfiles defined on one screen, each containing seven records per page. Notice that I use two different sets of indicators for SFLCLR, SFLDSP, and SFLEND, simply so I can control the subfiles separately. Again, in the real world, it might be the case that one subfile has more records than the other. One or both might even be empty. In my example, they will always be equal.

Before I move on to the RPG, there is one other technique I like to use with over/under subfiles. Notice that each of the subfile control formats contains an input-only field, CURSOR, that is placed before the first column heading. This field has been defined as non-display, or DSPATR(ND), because I don't care to have it displayed on the screen; its only purpose is for easy cursor movement. I am going to use CURSOR to allow the user to more easily travel between the two subfiles. Since both subfiles are active, by using the Tab key or Field Exit key, the user is able to move between the two subfiles with one keystroke. This is important because, with a load-all subfile, control is not passed back to the program when the Page keys are pressed; therefore, OS/400 decides which subfile to page to by interrogating (not harshly) the cursor position on the screen. In whichever subfile area the cursor resides, that is the subfile that is controlled by the Page keys. Without my CURSOR field, the user would have to use the arrow keys, and potentially many keystrokes, to maneuver between the subfiles. If the cursor is located in the HEADER or FOOTER format, the subfile that is controlled depends on how you coded the RPG.

The RPG code looks much like a typical load-all subfile program, except that I am loading and displaying two subfiles instead of one. If you've coded subfiles before, you are probably accustomed to seeing a WRITE operation, which displays the function key format, and an EXFMT operation, which displays to and reads from the subfile control and record formats. I do things a little differently in this program. The EXFMT operation actually performs a WRITE, followed by a READ. In my example I want to make both subfiles active at the same time, so I am going to write them both to the screen first and read from both of them when the user presses a valid Function or Enter key. The rest of the RPG is very similar to what you've seen before with load-all subfiles. It is not responsible for much because the DDS and OS/400 are controlling almost everything. When control is returned back to the RPG program, it is to allow the RPG to process the whole screen, not an individual subfile. Anything specific to one subfile (paging) will be accomplished by the OS/400 and is determined by the cursor location. When the cursor is located in a neutral spot (HEADER or FOOTER), the top subfile, SF1CTL, will scroll when the user presses the Page keys, because that is the subfile control record that was written last. Otherwise, the subfile that contains the cursor will be the one that is paged through. I have simplified the RPG to allow you to concentrate on multiple subfile concepts. In the real world, you are probably not going to load each subfile with the exact same data, unless, of course, you really want to emphasize that data.

One question you may have is whether or not you can display multiple self-extending or page-at-a-time subfiles on a screen. The answer is yes. However, you are going to do a lot more work in your RPG program. Instead of the DDS determining which subfile should be paged, you will have to do that in your RPG. It's no big deal, just more work. You will have to know where the cursor was when the user pressed the Page Up or Page Down key, and process the correct subfile accordingly. You may also have an issue if you're loading subfiles from the same data file. Maybe you are reading from a file and interrogating the data before determining which subfile to load. If you don't use the load-all technique, you're going to have fun trying to keep track of the file pointers associated with each subfile. I recommend that you use load-all subfiles when you're displaying multiple subfiles on a screen unless the subset of data to be loaded will contain more that 9,999 records. It's just a recommendation, but it seems to work for me well enough.

There you have it. The over/under technique is fairly straightforward and allows you to easily implement multiple, active subfiles on a screen using traditional subfile techniques. This is a great way to maximize data presentation on one screen. I will explain the more tricky, side-by-side technique in a future article, but for now, get back to basics and write some subfiles.