On 24-Mar-2015 08:52 -0500, (WalzCraft) Jerry Forss wrote:
On 24-Mar-2015 08:32 -0500, (WalzCraft) Jerry Forss wrote:
I migrated a vendor package to a new version.
When I check the file usage in the old version (Different library)
there is a file that is still being accessed that shouldn't.
There are multiple ways files are accessed including Stored
procedures, Crystal Reports and MS SQL code.
Is there a way to put a trigger on the file so when it is accessed
I will know about it? The file is NOT being updated, just read.
I can rename/delete the file and HOPEFULLY the offending code will
blow up. Just wondering if there is a trigger option.
<<SNIP>> It will help but was hoping for a more immediate
notification of access.
FWiW the topic is irrespective of [High Level] Language coding, so is
really unrelated to the RPG; directing a topic to a forum specific to a
language limits the audience, both of those who can assist and of those
who can benefit from the discussion as followers of that forum.
There are many ways, aside from passive methods such as journaling or
auditing that could assist in the described scenario. The rename of the
file, as already proposed, being very likely to expose immediately and
conspicuously any program still dependent. However most such active [vs
passive] methods depend upon both how the file is opened by the code and
how the code responds to the potential condition, thus the *hopefully*
remains an issue. For example, even a Read Trigger would fire only if a
data record was actually accessed and similarly for an INSTEAD OF
TRIGGER to fire, and use of an IOT also requires that the program
opening the file could open the VIEW instead of whatever the type of
DataBase File is currently. Anyhow, the _known_ likely is not that the
file is being read, but instead that the file is opened [and closed] per
last-used tracking is what is known; i.e. that the file is being read
rather than just opened, is likely only presumed.?
The one means to assuredly determine and be able to notify of the
open [for intent-read] is to use the Open Database File Exit Program
feature; the exit program could *actively notify* upon the request to
open, and before the open actually transpires with the option to prevent
the open activity. In combination with Change Object Auditing
(CHGOBJAUD), the impact to the system typically can be limited [unless
files and\or users are already audited.
<
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/xopendbf.htm>
_Open Database File Exit Program_
"...
The Open Database File exit program is called when a job is opening a
database file. This exit is called in the job that is attempting to open
the file. The exit program is passed a list of files referenced in the
open request and the open options. The exit program may set a return
code value to end the open request. When an open request is issued, the
operating system calls the user-written exit program through the
registration facility. ...
..."
midrange.com
