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

["Dan Bale" <dbale@xxxxxxxxxxxxx>]

IMO, pros & cons of triggers vs. journaling for this situation:

Triggers have the potential of making performance suffer more so than
journaling.

If something goes wrong with a journal, your production jobs don't go
haywire.  If something goes wrong with a trigger program, the brakes are
slammed.  (Depending on your real needs, you may want something like this
happen.)

Both journaling and trigger programs can be "deactivated" without any notice
to you (ENDJRNPF & RMVPFTRG, respectively), but I have found that "stuff
happens" on a system tight on space and detached journal receivers are the
first easy target to delete.  Normally wouldn't be a problem as long as the
RCVJRNE app is running, but this comes down whenever subsystems are ended.
So, in dedicated system mode, an operator may see journal receivers that are
detached and delete them if space is at a premium without realizing the
impact of that decision.  In most/all cases, the person using RMVPFTRG knows
exactly what they're doing.

hth, db

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Vern Hamberg
> Sent: Monday, July 12, 2004 11:49 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: Fastest way to get a unique identifier/tracking column
> changes
>
>
> Just wondering whether journaling would be better
> performance-wise. You can
> have before and after images. You already have system-wide
> uniqueness with
> library name, object name, member name and relative record number.
>
> Maybe?
> Vern