× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.