I believe "a trigger" would actually need to be instead, at least two
triggers? I would think both insert and update for sure, possibly a
delete trigger and even possibly a read trigger as well.? Another
similar means would be to journal the file and review what applications
open [ensuring *OPNCLO entries are not omitted] and\or update the file.
A bit more heavy-handed than triggers... The database "open" user
exit could be utilized to stop any application other than those already
identified as having been corrected, from opening the [member of the]
file. For lack of an "open trigger", the QIBM_QDB_OPEN registered exit
could suffice to implement that effect. The biggest difficulty is
differentiating what is an application using the internal description
versus the external description [having inferred the file is not
"program described" such that there is an external description] or even
if the request is just a dynamic open for which there is no concern for
a hard-coded description of the data by the program. Although at least
all cases of the "Database query open<>'0'" can be ignored, when only
for programs opening the file as program described are of interest.
On 13-Apr-2012 13:54 , DeLong, Eric wrote:
Attach a trigger to the file, then derive the caller (of the database
file I/O) and note the program name in a file... This won't work well
for program run very infrequently...
Dave on Friday, April 13, 2012 7:41 AM wrote:
I've been asked to delete a field from a physical file. I've found
all the obvious utilisations of this field, but how do I find all
the ones where the field may be internally described? The field may
have a different name and the file name may not even be the same.
This mailing list archive is Copyright 1997-2019 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