One of the coolest AS/400 programming "tricks" I ever learned was how to make a standard, 5250 green-screen subfile self-update. Using this technique, I can cause data to automatically appear on a user's display, without any keyboard input. The self-updating display file technique has been around for at least as long as the AS/400, but it's one of those things that, unless you've seen it done, just never dawns on you that it's even possible.

In terms of functionality, a self-updating green-screen subfile is very similar to the way an airline's flight schedules at the airport are constantly being updated. On the airline's display terminals, a flight's status can be automatically changed from "on-time" to "delayed" to "you'd better take a train," all within the space of a few moments, and without any keyboard input.

You can achieve that same type of functionality in your own green-screen applications by taking advantage of a seldom-used feature of display files: their ability to interface with AS/400 data queues.

We're going to build a sample application that does nothing more than display an empty subfile, and, if you so choose, you can automatically fill it with entries placed on an AS/400 data queue from an outside process. The complete code for this demo is available for download.

The first thing you need to do is create your AS/400 data queue. The data queue is really the heart of the technique and is, arguably, the most important component. The data queue can be either keyed or non-keyed, depending on your application's needs. In our example, it will be a non-keyed data queue. (For more information on data queues, check out "Data Queue Basics.")

Create the data queue with a maximum length of 1,000 characters. You can actually make it any length you want, up to 64,000 characters, but 1,000 is a good starting point for our sample application.

The next step is to create a standard, 5250 display file that contains a subfile. In the sample application, our subfile data is only five characters long, so I used the Subfile Line (SFLLIN) keyword to cause the data to appear multiple times on the same subfile display line. You don't have to code your own apps this way, of course.

If you look at the code, you'll see that the only really unique thing in this display file is the use of the keyword INVITE. INVITE allows us to programmatically "invite" input from sources other than the keyboard. By attaching an indicator (*IN75, in this example) to the INVITE keyword, we can control when we want to read from the keyboard, to check for user input, for example, and when we want to "listen" for entries being placed on the data queue.

One other unique happenstance of attaching a data queue to a display file is that, when the user presses a key on the keyboard, an entry is automatically placed on the data queue from the keyboard! We'll talk about this more in the next section.

When you create the display file, use the DTAQ parameter on the Create Display File (CRTDSPF) command to attach the data queue you created in the previous step to this display file:

The RPG program is also pretty simple. The first thing done is to clear the subfile. Next, the program goes into a loop that is terminated only when the user presses the F3 key on the keyboard.

Immediately upon entering the loop, the INVITE keyword's indicator is set on, so that we can "invite" input from sources other than just the keyboard. Next, a WRITE is issued to the display file's subfile control record format. This is different from the way you usually interact with display file record formats. Normally you would use the EXFMT keyword, which handles the issuing of WRITE and READ operations automatically. Here, we only want to WRITE the subfile control record format to display the empty subfile. We don't want to READ from it yet.

Once the WRITE has been issued, the next step is to see if there are any entries on the data queue. This is accomplished by using the QRCVDTAQ (Receive Data Queue) API. The API is pretty easy to understand and use. Basically, you pass the API the name of the data queue you want to receive data from, an empty parameter that will contain the length of the data queue's data, an empty parameter into which the data from the data queue is received, and, finally, a parameter to specify how long you want to wait for data to be placed on that data queue before timing out. In our case, we want to wait forever for data to be placed on the data queue, so the time out value is set to -1.

If an outside process, say a batch program running in the background, places an entry on the data queue, that entry will be received by this RPG program. What's more, and really kind of cool, if the user presses a key on his keyboard, an entry will also be placed on the data queue. What this latter entry does is allow you to monitor for keyboard input while at the same time monitoring for entries coming from some outside source.

Once an entry has been placed on the data queue, either from the keyboard or from an outside process, the program will evaluate the received data to see where it came from. This is really crucial, because you will probably want to do one thing if the data came from an outside process and something else entirely if the data came from the user pressing a key on the keyboard.

To determine where the entry came from, look in the first five positions of the received data. If the entry came from the keyboard, those first five positions will have the value *DSPF in them. Otherwise, those first five positions will be the first five characters of the data that the outside process loaded onto the data queue.

In our sample program, if the entry came from the keyboard, we first turn off the INVITE process, so that we can get the keyboard entry data. Next, we issue a READ to the subfile control record format, so that we can read the keyboard. And, finally, we check the status of the keyboard indicators *IN03 and *IN05. The keyboard indicator *IN03 is set on when the user presses the F3 key on his keyboard, which means he wants to terminate the program. In that case, set on *INLR and end the program.

The *IN05 keyboard indicator is set on when the user presses the F5 key. In that case, the user wants to run our background job to automatically fill the subfile on his screen. To achieve that, we'll submit a job to batch, using the QCMDEXC API, that does nothing more than perform a loop 160 times and load the same piece of data over and over to the SELFUPDQ data queue.

If the received entry from the data queue did not contain the value *DSPF, then the data came from some outside source. In that case, extract the data from the received data parameter and use that data to fill the subfile field. To write data to the subfile, you'll first need to issue a WRITE to the subfile control record format, and then a WRITE to the subfile record format itself.

The final piece of our sample is the CL program, named SELFUPDC1. This CL program is submitted to batch when the user presses the F5 key from the RPG program. The CL program performs a loop 160 times, each time placing an entry on the SELFUPDQ data queue. When 160 iterations have been achieved, the program will end.

In your own applications, you would likely have some outside source that loaded entries on the data queue, based on some more realistic criteria such as product updates or other appropriate events.

That's all there is to creating a self-updating, 5250 green-screen subfile. Download the sample code for this application and give it a try. The only thing you'll need to do before you compile the code is to remember to create the data queue. Otherwise, once you compile the code, it's all ready to test drive.