×
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.
On 20-Oct-2011 09:07 , Richard Schoen wrote:
Does anyone know of a good way to track when a source member is
opened for editing ?
I would expect the best way would be, to make the editor send
whatever is the desired tracking entry\message, whenever the RPGxxx
source-typed [making my reply somewhat on-topic, I suppose] database
source member is opened by that editor. Though from the following
queries, perhaps what editor(s) will open may be unknown or otherwise
the desire is instead to track all open-for-update of the source member
irrespective of the update interface [editor, SQL, DFU-like, etc.].?
What about open for insert [output-only] versus update; e.g. an FTP
APPEND subcommand or similar.?
I know a database trigger will work to catch data changes, but I
don't think it catches file opens does it ?
Does "catches" imply an ability to intercept, as in synchronously, or
perhaps "to track" means to imply the knowledge of open-for-edit could
be after-the-fact, as in an asynchronous review of that activity?
Journaling including open entries but also includes I\O. Perhaps member
change auditing entries might suffice; I can not recall if they occur
during open or close [and only when source changes occurred].
There's also the database file open trigger, but that one might cause
system performance issues.
Presumably the latter is in reference to the database-open optionally
registered exit point QIBM_QDB_OPEN which applies to ¿all? non-system
database member opens.? Since the database trigger is applied to all
members of any specific named *FILE [i.e. ADDPFTRG FILE()], that the
implementation of the DB-Open user-exit is not specific to one *FILE
seems contrary to the term\implementation of "trigger". While I
personally would avoid using that exit, I expect that a properly
implemented exit program could be a minor impact; the user-exit program
should be resolved-to and invoked-by a program object address, so given
minimal automatic storage, auto-initialization, minimal data copy,
cached addresses for resolve\write\enqueue activity, the processing of
the exit could be almost unnoticeable for the impact on the normal open
activity.
I alluded in to at least one similar past inquiry [some links below],
that an actual database file trigger capability for the action of "open"
might be a nice feature\enhancement for some people to have; possibly
even available both for the *BEFORE and *AFTER, providing details about
which and how the file.member was requested to be opened, and further
details about the member that was located\resolved to be opened [and
which algorithm was utilized to locate the member for open]. Something
for which submitting a design-change-request might be worthwhile, if
such capability is desirable.
Subject: "Trigger programme without a trigger."
http://archive.midrange.com/rpg400-l/200806/msg00103.html
http://archive.midrange.com/rpg400-l/200806/msg00124.html
http://archive.midrange.com/rpg400-l/200806/msg00176.html
Regards, Chuck
midrange.com
