×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
midrange.com
