Only a Physical file contains data. Logical files just contains pointers for processing the data in a specific sequence and/or subset of data.
When a record is added/changed/deleted in a physical file, the system has to put a lock on the it and then go out to check and update any logical files before it can release the lock. While the amount of time to do this is hardly measurable, it can be signicant if massive batch updates are done to a file.
If you are using the Select/Omit option in your DDS and using DYNSLT, the above process does not need to be done at record update time.
Where this is benefical is when yourt selection process includes almost all the records in the file. Now when you process using DYNSLT, it will read all the records in the file, but do the selection of which records to process at that time rather than having done all the maintenance ahead of time.
Here's an example that might make it more clear.
Lets say you have a very large file and one of the fields is a STATUS CODE and that value is constently changing with different batch processes.
You have a Logical that selects only a specific status code.
This Logical is only used for a month end report and at the time that it runs most of the records will have be set to be selected.
So now by using DYNSLT, the program will take about the same amount of time to process but all the access path maintenance thoughout the month did not have to be done.
If you are familiar with SQL, it is kinda like using a view. Only when you open the view does it process the query to determine the data set. In a similar manner, only when you open a DYNSLT logical does it determine the records to include/omit.
CharlieBrowne gave a good summary of DYNSLT, and BigKat appropriately compared it to a SQL VIEW.
Multiple factors go into choosing DYNSLT or leaving it out.
A logical file might be in use by thousands of users (or jobs) at the same time. It won't always be most efficient for each individual job to make dynamic selection. If the system can do it once for the access path, then each job can rely on that access path without dynamic selection.
But if a logical file is rarely in use by jobs, the system won't have to take time to update that access path every time the physical file is changed. The rare job can make its selection dynamically.
Number of jobs, number of records, number of updates and other factors might make significant differences in performance. The differences might be in individual jobs (localized job performance) that use that logical file, or they might show up in all jobs (system-wide performance) as DB2 takes more or less time in updating the access path.
Tom
Free Guide: Managing storage for virtual environments
Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!
62,385 pts.
Discuss This Question: 6 Replies