RE: audit source member adds/mods/deletes

Thanks Mark.

Only problem, as I stated in my original post, is that how would a new or
restored file be recognized, in your example, for adding a trigger?

Beyond that, I'm not sure I want a trigger program on something like this,
if only for the remote possibility that a bug in the trigger program could
cause a member to not be saved and, thus, "trigger" the TrmPrgrmr
Option(*Immed) command.

Can anyone weigh in on the pitfalls of sticking a journal on the QADBXREF
file?  Or does that also have the potential of issuing a MakeAMess command
as well as the TrmPrgrmr Option(*Immed) command?

TIA, db

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of
> mwalter@xxxxxxxxxxxxxxx
> Sent: Monday, June 28, 2004 9:09 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: audit source member adds/mods/deletes
>
> Can you add a PF Trigger to a source physical file?
>
> Thanks,
> Mark
>
> Mark D. Walter
> Senior Programmer/Analyst
> CCX, Inc.
> mwalter@xxxxxxxxxx
> http://www.ccxinc.com
>
>
>
>
>
> Good Monday morning!
>
> There's gotta be a way...
>
> I want to be able to automagically track the user ID that changes
> any given source member.
>
> Because we are moving towards using the WDSC source editor, it can't be
> something that only hooks to SEU.
>
> I know a little about object auditing, but the problem there is that the
> source physical file must already be known (defined for audit) before
> member adds/mods/deletes can be audited.  Am I wrong about that?  Case
> in point: I create a new source physical file, or restore one from
> backup, and I need it to be immediately audited.
>
> Thinking "out loud": Could I stick a journal on QADBXREF and a
> never-ending batch job that RCVJRNE from that to catch new files to
> audit?
>
> Is there a more "elegant" solution?
>
> TIA, db