Sometimes the only answer to a problem is a work file, and ILE RPG makes it really easy to use one.

Work files aren't exactly sexy. With it being so easy to embed SQL into RPG, work files seem absolutely passé. Even back in the olden days, the joy of OPNQRYF allowed us to avoid the need for work files. (If you find yourself suddenly twitching and muttering to yourself, take a breath; this article is not about OPNQRYF!) Today we revisit the concept of work files and see where they still makes sense and just how easily they fit into the new world of ILE.

If They Didn't Want Us to Use Work Files…

…then they wouldn't have made them so darned easy to use! Seriously, the various nuances of the dcl-f specification make it so easy to use work files that you'll never need another OVRDBF (which was always a problem, especially with OPNQRYF). But before I delve into those capabilities, let's first discuss why you might need work files in the first place. It's true that the idea of small files being passed from one step of a job to another is out of fashion these days, and for the most part I agree with that sentiment. Happily, you no longer write data entry programs that dump data into a file only to be sorted using FMTDTA and sort specifications. (And if you were twitching over OPNQRYF, I can only imagine what FMTDTA did to you!) But the rise of SQL has given us situations where that old, hoary concept still has some real value.

Let's take the concept of a complex report. SQL is fantastic at joining and aggregating data, and as long as the data points exist to link the records, you should have no problem grabbing all the records using an SQL statement. And if that's all there was to the task, you could create an SQL cursor, spin through the data, and generate the report. But situations exist where that simply doesn't address the requirement.

The simplest case is when the data isn't printed but is instead directed to a file to be used later, either in an external reporting tool or simply to get pulled down by the user into a spreadsheet. Yes, you could generate a spreadsheet using one of the great tools out there (like Scott Klement's HSSF API), but the users may already have a spreadsheet where they simply want our data. Having a single file on the system in that case doesn't work because one user could wipe out another user's data. Instead, the easy answer is to create a work file unique by either name or member.

Another case occurs when you need more in-depth intermediate calculations than SQL is comfortable with. As an example, you may want to perform a complex data analysis that relies on prices. The goal is to find invoice lines for a certain customer where the actual price is significantly different from the expected price. You may need to look at several places (a customer-item record, a catalog, and a price agreements file) to determine whether there are price agreements in place before being able to get the expected price for a given order line. That's not something easily done in SQL, and even if it were, it probably wouldn't be the sort of thing you want to do for every row. Instead, you might grab all the item lines for the customer and stuff them into a work file. Then you run an RPG program to get the expected price for each line and at the same time calculate the percentage difference, updating columns in the work file. Finally, you create an SQL cursor to sort those records by percentage. Yes, this can all be done in SQL (the most extreme case being that you have to write a stored procedure to get the price), but the overhead could be quite extensive.

Note that I'm not advocating work files for every situation or even for a lot of them. I'm just saying that they can come in handy and that ILE RPG makes it particularly easy to handle them.

Using a Member

Case one is the simplest: add a new member. In your ILE RPG program, all you have to do is specify the EXTMBR keyword on the file specification. The trick is to get that member name into the program. This is the easiest technique:

      dcl-f WORKFILE keyed extmbr(iMbr);

      dcl-pi *n;

       iMbr char(10);

      end-pi;

You create a file named WORKFILE in one of your primary database libraries. You add a member and add records to that member. You might use the job number or the user ID, or allow the user to specify a member. Whatever you do, keep track of the member and then pass it in to your RPG program as a parameter. By taking advantage of the EXTMBR keyword on the file specification, you can instruct RPG to open the appropriate member as specified in the input parameter.

Using a File in QTEMP

However, you probably know that members aren't exactly SQL-friendly. You have to run the ADDPFM command to add a member and then create an ALIAS to that member. The ALIAS sticks around forever until you drop it, as does the member. You can remove some of the permanence issues by using QTEMP, but if you're going to do that, I suggest simply moving to QTEMP in the first place. Create the file in QTEMP, either with the same name or a different name (which you choose depends on the application and to a lesser degree on your library list). Using the same name is the easiest. Here's the code for that technique:

      dcl-f WORKFILE keyed extfile('QTEMP/WORKFILE');

No parameters of any kind. The program will look specifically to QTEMP for the file regardless of your library list. You can of course simply set your library list correctly, and you won't even need the EXTFILE keyword. However, let's say you want to allow for a little more flexibility in the file name. Theoretically, you might want two different versions of the file that you can switch between.

      dcl-f WORKFILE keyed extfile(iFile);

      dcl-pi *n;

       iFile char(21);

      end-pi;

In this case, you pass in the fully qualified named of the file rather than the member. No ALIAS is required. The name of the file is inconsequential; just make sure you pass it in qualified and blank-padded. For example, let's say you have two files, WORKFILE1 and WORKFILE2, in QTEMP. You can use 'QTEMP/WORKFILEA' as your input parameter to point to WORKFILE1 (and obviously change it to point to WORKFILE2). Just populate two copies of WORKFILE in QTEMP and then call this program with the appropriate value in the first parameter.

Variations on the Theme

The work file wouldn't have to be in QTEMP; it could be in another library but with a unique name. Or even a unique name and member; every combination can be used. Note, though, that these all require the name to be known when the program starts. What if you want to calculate the name dynamically? Here's a case where the member name is generated from the date.

      dcl-f WORKFILE keyed extmbr(wMbr) usropn;

      dcl-s wMbr char(10);

      wMbr = 'MBR' + %char(%date:*ymd0);

      open WORKFILE;

In this case, the program will attempt to open member MBRyymmdd, where yymmdd is today's date. Because the member name isn't known until after the program starts, you'll need to open the file manually; add the USROPN keyword to the file specification and then use the OPEN opcode to open the file once you've generated the member name.

When the Time Is Right…

As I said at the beginning, work files aren't often the right tool for the job, but in those cases where they fit the requirement, ILE RPG makes it very easy to implement them. And now that you know how to use work files, in subsequent articles I'll try to spend some time on how to generate them.