Re: Physical Files

On 25 Apr 2013 11:39, Stone, Joel wrote:

CHGPF SIZE(*NOMAX) does require exclusive use of the file for a
moment.

Or many moments :-) over which the effect is applied for each member of the database physical file.

DSPPGMREF will identify SOME of the programs which use the file, but
not all.

DSPPGMREF will not identify the following, and surely other methods
of accessing a file:

- anytime a file is over-ridden using OVRDBF
- OPNQRYF use of a file
- SQL use of a file
- embedded SQL
- QUERY/400 use of a file
- and then there are the EXTERNAL file usage such as JDBC, ODBC,
SQL, Excel, etc.
<<SNIP>>

Indeed dynamic and ad-hoc references would necessarily have to be inferred from past experience [e.g. by audit logs, the database open exit, or perhaps by journaling which does not omit *OPNCLO entries, or a read trigger if one exists for the file (not recommended for the purpose)] or presumed to be possible future actions, as something that can not be tracked by making an inquiry of compiled objects for what files they reference.

However DSPPGMREF can identify many of those things noted as unidentified, *if* they are coded within a /program/ being interrogated for its /where used/ information [which is what is presented by the DSPPGMREF, as retrieved from the Object Information Record]. All of the requests OVRDBF, OPNQRYF, and RUNQRY, each define their "FILE"-like parameters with PARM FILE(other_than_*NO), such that compiled CL using those commands will divulge the file references. Also static embedded SQL records files in a FROM-clause in the where-used information. Since v6r1 I believe, new *QRYDFN objects will also have where-used information saved in the object OIR [and support for OBJTYPE(*QRYDFN) added to DSPPGMREF, as well the *QRYDFN is part of *ALL], and a program was made available to expose that information for any Query Definition objects that either remained on disk or were restored from, a prior release.