Re: Need To Journal Files & System Impact

With all the pronouns, I am not sure at this point, what is this, that, or it. But use of CRTDUPOBJ and Save\Restore to make copies of objects is a potential issue irrespective of whether each of the files involved in that activity are all journaled to one journal or journaled across one or more additional journals. The effects of QDFTJRN and STRJRNLIB must be considered. As well, realize that an object created with restore is going to have the same JID as the existing object on the system, so the journaling can not be maintained even to the same journal [without an override to how journaling is started], and the restore should log an error condition informing of that condition.

Regards, Chuck

On 20-Feb-2014 13:19 -0800, Evan Harris wrote:

This approach is fine so long as you stick to it, but you could end
up with an awful lot of individual journals. There might be some
complications around CRTDUPOBJ and save/restore between libraries (if
you do that) that might also complicate what journal things end up
going to - I have not thought this through yet.

If you are using the journals for a HA product this becomes terribly
difficult to manage as ideally you want to group common
libraries/resources together in the same journal (at least in my
experience).

On Fri, Feb 21, 2014 at 8:41 AM,<rob@xxxxxxxxx> wrote:

There are those who will argue that putting the journals and
receivers into the same library as their data also ensures this.
That's all well and good until you start getting cross library
transactions you want to use commitment control on.
I make a sale. I want it to update customer data in ARLIB. I also
want it to update salesperson data in CRMLIB. And I want to use
commitment control. If the operation fails it should roll back the
previously written data. Hard to do when your data resides in two
different journals and journal receivers.