The Retrieve Database File Description (QDBRTVFD) API is by far one of the most challenging and discouraging APIs that ever left IBM’s drawing board alive. But because it is also an extremely powerful API, I keep coming back to it whenever database files are involved in the equation. There’s no detail in the complex and nested structure that makes up a file object that is out of reach for the QDBRTVFD API. Whether physical files, logical files in various flavors, any kind of file field information, key information—you name it, it’s all there—buried somewhere in the many file description layers and structures exposed by this API.
Today’s API by Example uses the QDBRTVFD API to catch and eliminate the dangers and problems potentially caused by misplaced logical files. While there can be valid reasons for a logical file to be located in a library different from a physical file it is based on, it can also sometimes be traced back to a mistake or misunderstanding on the part of the developer creating the logical file. Should that situation arise, the Analyze Logical File Integrity (ANZLFITG) command will help you quickly identify and correct the problem.
If you don’t have a completely waterproof separation of your production and development environment—whether physically or by means of resource security—as well as a thoroughly verified procedure for moving objects between one and the other, there’s a risk that you at times for whatever reason might end up with logical files in test libraries pointing to a physical file in a production library or vice versa. Subsequently running production programs might perform updates in partial against test data, or likewise, testing programs under development in turn will update your production data. Encountering such situations will in a worst-case scenario keep you occupied for quite a while before you have reestablished the database integrity.
Another issue originating from logical files located in libraries different from their physical files’ libraries relates to save and restore dependencies. At releases earlier than 6.1, it’s impossible to restore a logical file if a based-on physical file doesn’t exist in the library in which it was located when the logical file was saved. So if the logical file library is restored before the physical file library, the restore will fail. Given, for example, a disaster recovery situation, failing to comply with this restriction can add significantly to an already tense atmosphere.