Rid your system of crossed up logical files

Every system runs the risk of logical file views that aren't pointing to the correct physical files. I have run across this many times so it is one of the first evaluations I do for any new client.

If the logical file is simply used for reading a file incorrect results on reports and/or displays can occur, for example. Even worse though is if the logical is used for updating then the physical file being changed may be the wrong one. This can cause test programs to update files in your production environment and vice-versa.

Fortunately checking your system for and ridding yourself of "crossed-up" logical files is fairly easy.

We need only enough information about each file to determine the file type, the library where the file exists, and the files' parent library. We can retrieve all of this by using DSPFD to dump a list of all logical files in a library to an outfile. If the outfile does not exist the DSPFD command will create it. I normally run this one library at a time and especially for libraries that might have some ongoing development.

1. Command String

DSPFD FILE(TESTLIB/*ALL) TYPE(*ACCPTH) OUTPUT(*OUTFILE) FILEATR(*LF) OUTFILE(MYLIB/LOGICALS)


2. Then select logical files where the resident library is not equal to the parent library.

RUNQRY QRYFILE((MYLIB/LOGICALS)) RCDSLT(*YES)

Select Records


Type comparisons, press Enter. Specify OR to start each new group. Tests: EQ, NE, LE, GE, LT, GT, RANGE, LIST, LIKE, IS,ISNOT...

AND/OR                          Field                Test Value  
                                        APLIB             NE                    APBOL

The same query can be executed in SQL as such:

select apfile, aplib, apbof, apbol from mylib/logicals where aplib <> apbol

Of course there will be times when the different locations are acceptable. However, the list will usually be manageable and the mistakes should jump out like a sore thumb. Any crossed-up logical files will need to be recompiled over the correct library list. Depending on the number of changes happening on your system it may be a good idea to check again periodically.

The DSPFD "Type of information" parameter was set to *MBRLIST since the objective is to treat each member. However, if a situation only needs to see file level information then the *BASATR (base attributes) parameter setting might be more efficient.