Unless you have your database files journalled, you have to start from the program end to see which program uses which file instead of from the file end to check which file is used by which program. This is why DSPPGMREF and ANZPGM are used in this case.

Since DSPPGMREF can be used to create an outputfile, you can then use query to find out which programs use a particular data file. You only need to run DSPPGMREF once across all the objects in your program library(ies) and you have all the necessary data.

If you have journalling, you can check in the journals to see which programs have accessed a file, but then if you have something like a year-end procedure, you will need journals for a year or more to find all the programs that access your file. Most people don’t have that sort of disk space available for journal storage.

Regards,

Martin Gilbert.

Hope somebody can eloborate on this…

thanks
Ram

The OVRDBF can normally be picked up on the DSPPGMREF if it’s hard coded, however if used in combination with data files and data areas, etc it can be much harder to find – you will probably see files referred to as something like &FILENAME, then you have to look to see where the variable is coming from.

Regards,

Martin Gilbert.

OVRDBF in a CL or RPG can cause the program to use a file other than the one shown on the DSPPGMREF command. Also User Open files can be redirected with the F spec keywork Extfile.

The OVRDBF coupled with an OPNQRYF can make access even more difficult to identiy.
Imbedded SQL commands can use files that are not identified in DSPPGMREF.

Query 400 also uses logicals.

Phil

Don’t forget that there could always be programs that get missed by whatever method you use to look for this – for example where file names are stored in a file or data area instead of being coded in your program.

Regards,

Martin Gilbert.