RE: Fastest way to get a unique identifier/tracking column changes

["Reeve" <news@xxxxxxxxxx>]

Hi Frank,

Whether using journaling or a trigger, you get the same thing: a before and
after value, and you write the value to a file.  Using journal receivers,
you build all your logic into one processing program which has to be managed
operationally; with triggers, you build logic into each trigger program and
risk some performance degradation.

I don't believe the results will be different depending upon which approach,
trigger or journal receiver, you use.  It's about implementation, stability,
and performance. 

You're correct about object authority controlling receiver deletions.

Fortunately, I don't have to make a decision right away; I'm still
uncommitted to a particular approach.

My thanks to you and the rest of the Group for your contributions!

-rf

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Frank.Kolmann@xxxxxxxxxx
> Sent: Monday, July 12, 2004 6:30 PM
> To: midrange-l@xxxxxxxxxxxx
> Subject: RE: Fastest way to get a unique identifier/tracking column
> changes
> 
> 
> 
> 
> 
> Hi Reeve,
> 
> As I am using journalling I must address this crimp.
> Surely when a user wants to know what changes have happened to this
> customer or this product this does not equate to what changes have
> happened to a row in a table.  Is this a case of the classic childs swing
> 'what the user really wanted' vs
> 'what the engineer designed'  vs
> 'what was actually built'
> If I cannot address the 'really wanted' issues with journals then I
> must reconsider.  Even if the 'primary key' changes in a record
> 'God forbid' I believe I will be able to track this with sufficient
> rigor using journals.  Issues such as a programmer or operater deleting
> revceivers can be readily address using object security.
> What am I missing.
> 
> Frank Kolmann
> 
> >date: Mon, 12 Jul 2004 15:12:19 -0400
> >from: "Reeve" <news@xxxxxxxxxx>
> >
> >Note on using journals: Table/member/RRN is an inspired thought (even
> >though I don't use multi-member files for mission-critical functions),
but
> >there are still a lot of programmers and operations managers determined
> to
> >reorganize files whenever possible (i.e. you're not looking).  If V5R3
> >reorg-while-active physically changes the RRN (which I assume it
> does),
> >that puts a crimp in the journal receiver solution.
> >
> >-rf
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.