Re: system event trigger whenever a source file member is updated -- MIDRANGE-L

this has come up before, and I don't know, but has anybody considered using
the object auditing?

Create the audit journal receiver and journal, change object audit on the
file to *change and then use the RCVJRNE exit to process the records?

Years ago, maybe a decade now, I had written a program that pulled these
entries for things like object restore and moves and renames so that we
could track objects that the programmer's were manipulating across the
systems. While I don't remember offhand what entries the changes against a
file produce in the journals, I believe it was all object access for
change...

While triggers are record and record group oriented, adding or changing
members should probably show up in the audit journal.

===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified Specialist - iSeries Administrator
 -- IBM Certified Specialist - RPG IV Developer

"Suppose you were an idiot...
  And suppose you were a member of Congress...
  But I repeat myself."
    - Mark Twain

----- Original Message -----
From: "Dan Bale" <dbale@samsa.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, March 12, 2002 6:07 PM
Subject: system event trigger whenever a source file member is updated


> Am looking for a system event trigger of some sort that would tell an
> application that a file's member has just been updated, deleted, or added.
> All physical files, all members.  Specifically, all *source* physical
files.
> I would be happy to know this at the file level, i.e., a "member event"
has
> just occurred on file DJBLIB/QSRC; then my app would interrogate the file
to
> see which member(s) have just changed, or been deleted or added.
>
> The idea behind all this is to utilize a WRKMBRPDM type tool (which I've
> built and named FSM) that isn't limited to showing members for a single
> library.
>
> Currently, I run:
>   DSPFD FILE(*ALL/*ALL) TYPE(*MBR) OUTPUT(*OUTFILE) FILEATR(*PF)
> each night, and my FSM derives its member list from that.  This is
> sufficient 99% of the time, but the other 1% has been known to burn me
here
> and there, as members get created, deleted, moved, etc.
>
> Had high hopes pinned on journaling the QADBXREF file but, unfortunately,
> the change timestamp does not get updated for any member event.  I could
> still journal it to determine when source files are added or deleted.
>
> There's just gotta be a system-maintained member-based file somewhere.  A
> user-space maybe?  How does DSPFD TYPE(*MBR) gather its data?  I would be
> willing to utilize an "unsupported" reference.
>
> Leif, do you have something on this in your e-book?
>
> TIA,
> - Dan Bale
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>