Defining the problem
A "work file" is a temporary physical file that a program can use for many purposes. However, when the program stops running, the work file is typically deleted. Usually, we resort to work files when we need some temporary storage the size of which will be changing. A work file is often used when an array is needed -- often an array of data structures -- but the programmer anticipates the number of elements will exceed the 32,767-limit. If you think about it, a file is just like a data structure array (i.e., an array where each element is an identically-defined data structure); a file is an array of records where each record is an identically defined data structure.
In most (if not all) cases, a work file design can be converted to a dynamic array design. You can even define the program data structure based on a file (e.g., the work file).
The main benefits of using dynamic memory are:
1. The program will be much more efficient (i.e., run faster) because of the elimination of the system overhead involved with file initialization and file I/O.
2. Eliminating the hassles involved with work files. These include making sure that the empty template file doesn't get deleted by accident and eliminating the need to create a temporary work file in QTEMP from the template file (and possibly eliminating the CL program that does it).
3. Everything is contained in one program (this stems from number 2 above).
Is the design compatible?
The required data access method is the litmus test for determining if dynamic memory can be used instead of a work file. If the design relies heavily on keyed access using CHAIN, SETGT, READE, and similar I/O op-codes, then it may not be a good candidate for dynamic memory. However, with the recently introduced %SubArr RPG built-in function (V5R3), sorting dynamic arrays has become much easier, so even keyed access may not be an impediment. Give it some thought and see New built-in function simplifies dynamic array handling for more information.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.