There is more than meets the eye to the Create Logical File (CRTLF) command. If you are accustomed to creating/compiling logical files by quickly typing option 14 and pressing Enter in PDM, you may be missing a lot. The same holds true if you type just CRTLF LIB/LGLFILE. Even if you prompt the Create Logical File command, you may be missing some important command parameters if you don't call them down with the F9 key.
Understanding the seldom used MAINT parameter
The Access path maintenance (MAINT) parameter on the CRTLF command is frequently misunderstood, if known at all. Therefore, many programmers and database administrators seldom take advantage of it, electing simply to take the default parameter value.
The MAINT parameter allows you to specify how and when a logical file's access path is maintained as data in the underlying physical file is added, deleted or otherwise changed. The default value for the MAINT parameter is *IMMED. At first glance everyone thinks, "Oh ya, absolutely! I want the access path maintained immediately. If a program is using the logical file, I want it maintained as changes are made."
What many don't realize is that this parameter does not control access path maintenance while the file is open. It controls things when the file is closed (i.e., not in use).
When data in a file is changed, whether it is done directly using the physical file or indirectly using a logical file, it can potentially affect all the other logical files built over that physical file -- even when they are closed.
The question then becomes: When do you want the access path of a closed logical file maintained or updated? Do you want it updated immediately while it is closed and not being used, or do you want it updated the next time it is opened for use?
This still might seem like a proverbial no-brainer, until you start thinking about the different logical files you have on your system and how they are used. Think about those logical files that are used once a month for end-of-month processing -- and used in batch to boot. Even if a logical file is used as often as a few times a day, you need to consider whether it is worth using processing power all throughout the day for something that is used infrequently.
Why not just update the access paths of those logical files when they actually get opened for use?
Delayed access path maintenance does the trick
One of the other two valid values for the MAINT parameter is *DLY, which stands for delayed access path maintenance. Remember, the MAINT parameter does not control the access path maintenance when the file is open; when a logical file is open and in use, access path maintenance is always done immediately. Instead, the MAINT parameter dictates how the access path should be maintained when the logical file is not in use (i.e., closed).
Delayed access path maintenance is an excellent choice for occasionally used logical files. When delayed access path maintenance is set for a logical file, and the data in the underlying physical file is changed, the system uses the following logic to maintain the access path:
- Update the data in the physical file. This is always done no matter how the logical file is configured.
- If the logical file is open, update its access path immediately. This is true no matter which job has the logical file opened. DONE!
- If the logical file is closed, record and save the access path information, if any, associated with the updated physical file data.
- Update access path the next time the logical file is opened. With the access path information recorded and saved, the system is ready to re-sort (i.e., maintain) the logical file's access path, but there really is no need to do it until the logical file is needed. So, only when the logical file is opened next will the system update the access path with the new access path information.
There is one caveat: Delayed access path maintenance cannot be specified for a logical file that requires unique keys.
The other value for the MAINT parameter
In case you are wondering what the other value the MAINT parameter can be, it is *REBLD. Rebuild is a throw-back to the early days of business computing when memory -- in this case disk space -- was tight. However, it still might have some value for logical files that are very rarely used (e.g., for end-of-year processing).
The *REBLD value causes the logical file's access path to be rebuilt from scratch each and every time the file is opened for use. Furthermore, the access path is deleted when the file is closed and no longer in use. Like *DLY, *REBLD cannot be specified for a logical file that requires unique keys.
-----------------------------------
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.
==================================
MORE INFORMATION
==================================
- What do these access path terms mean?
Confused by the various terms that are used when discussing acess paths? Site expert John Brandt defines those terms, including file indexes and logical files and helps you make sense of them.
- Use DSPFD to track file accesses and nip performance issues in the bud
It is often useful to know which are the most heavily accessed files in your system. Perhaps you would like to know which files have the most updates, deletes or reads. Such information can be useful in profiling individual programs, spotting performance bottlenecks and ensuring your system runs smoothly. There are many ways to determine such information, including performance tools, but journaling may be a better option.
- Reorganize with CPYF *REPLACE
You can increase the speed of your CPYF replace by changing all of the logical files that are based on the destination physical file to MAINT(*REBLD) and then changing them back to MAINT(*IMMED) after the CPYF completes. Search400.com member Dan Sylvester did this on a file that had a whopping 55 logicals and witnessed a speed increase of 2000%.
