On 02-Nov-2011 17:55 , Sam_L wrote:
Each night we run job TSTCRT to create a copy of production data for
testing, thus:

SAVLIB PRODLIB to QTEMP/SAVF
CLRLIB TESTLIB
RSTLIB from QTEMP/SAVF to TESTLIB, OMITOBJ(PRODLIB/QDFTJRN)

Every morning I find that the objects in TESTLIB are journaled to
the production journal. I don’t want that.

That would be normal IIRC for standard database restore [i.e. without a QDFTJRN *DTAARA], with errors about a duplicate JID being logged as a diagnostic. IIRC the database restore processing would "correct" the error condition by establishing the same journal association as was established during the save request, but as required by journaling, with a new unique JID.

DSPLIBD of both PRODLIB and TESTLIB show that neither library is
journaled. We're on V6R1.

Not sure what DSPLIBD exposes with regard to journaling since a "library" object is not journaled; and unfortunately, automatic journaling for objects within a *LIB was integrated not with CRTLIB\CHGLIB, but with a data-area implementation using QDFTJRN. Any individual objects within a library may or may not be journaled.

QDFTJRN exists in PRODLIB and all objects are journaled.
QDFTJRN does not exist in TESTLIB. (Thought it once did.)

We’re running Mimix and it uses remote journaling, but we don’t
replicate the TESTLIB library.

The journal records for TESTLIB show that it is job TSTCRT that is
starting the journaling.

Any thoughts on why journaling is starting?

My prior "IIRC" comments.

Maybe I should have the OMITOBJ(QDFTJRN) on the SAVLIB?

Whether SAVLIB or RSTLIB would seem moot.?

Or there is some obvious parm I’m missing that says “don’t journal”.

Is there a *NONE [or similar] special value in the QDFTJRN feature? I would think replacing the RSTLIB with scripting the restore in the following manner would assist:

CRTLIB TESTLIB
CRTDTAARA TESTLIB/QDFTJRN /* specify explicitly not start any journaling */
RSTLIB RSTLIB(TESTLIB) /* either OMITOBJ(QDFTJRN) or OPTION(*NEW) MBROPT(*ALL) */

I just did a quick peek at the docs for v5r4 and saw that the special value *RSTOVRJRN and naming a non-existent journal should effect no journaling... if I read the following correctly, so the above script should help:

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzaki/rzakiautostrjrnl.htm
"You can use the *RSTOVRJRN keyword to override the journal used at save time. After you specify the *RSTOVRJRN keyword in the QDFTJRN data area, the operating system always records the restore operation to the journal that is specified in the QDFTJRN data area. In this case, any journal used at save time is ignored. PTFs SI24505, SI24794, SI24812, and SI24864 are required to activate this *RSTOVRJRN keyword function.

If the object being restored still exists on the system, the *RSTOVRJRN keyword is ignored during the restore operation. When the *RSTOVRJRN keyword is in effect, if the journal named in the QDFTJRN data area does not exist on the system, the restored object will not be journaled."

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.