Software analysis tools like Pathfinder attempt to resolve those
variable-name references.
-sjl
"Stone, Joel" wrote in message
news:mailman.2979.1366925583.7202.midrange-l@xxxxxxxxxxxx...
To be more specific:
Yes dynamic and ad-hoc file references cannot be predicted, however many
shops use variable names for CL file commands; these will not be picked up
by DSPPGMREF and resolved to the file of interest.
OVRDBF &fileA &fileB
OPNQRYF &fileC
Also many shops use SQL (which is not compiled) in production runs - they
are not ad-hoc nor dynamic ie the SQL stmts don't change from one day to the
next; these file names will not be picked up.
Also for many shops with OS prior to v6, QMQRY and Query/400 will not show
files using DSPPGMREF.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, April 25, 2013 3:11 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
midrange.com
