On 28-Jan-2015 09:48 -0600, Mike Cunningham wrote:
We have one system where the entire schema was created using SQL
commands. Journaling was setup automatically. All was good.
CREATE SCHEMA [or CREATE COLLECTION] will effect automatic creation
of the *JRN object QSQJRN to which all TABLE objects for CREATE TABLE
will automatically be journaled. Both because the journal object name
is not unique across the system\iASP [for which recovery potentially can
be impacted] and for issues like the origin for this topic, use of the
defaults for those [synonymous] CREATE statements is not ideal.
We then had a need to replicate the entire schema to a new name for
a training so saved the production library and restored to the
training library. That all appeared to work. All objects that were in
the production schema were created in the training version. Including
the journal object.
Apparently the action was to effect Restore Library (RSTLIB) to a new
library name; and on the same system\iASP? Besides the journaling, the
catalog VIEW objects would be in error with that scenario; recovery for
that is to CALL QSQXRLF (DLT 'NewLibName') optionally followed by the
same call but the token CRT for the first parameter to effect the
recreate of those VIEW objects with the new library name.
What we didn't notice was that the training files were all attached
to the journal in production. It worked but was not as it should be
There should have been a bunch of ugly-looking diagnostic conditions
logged during the restore, to indicate the duplicate-JID condition being
resolved. I seem to recall that the restore request would have ended
with an exception, to bring attention to the logged conditions.?
so we were doing a process of ending journaling on all the training
library tables and access paths and reattaching them to the journal
in the training library. Was on a command line using ENDJRNPF and
ENDJRNAP then STRJRNPF and STRJRNAP. That all went OK until we hit an
SQL VIEW. The VIEW object was showing as an LF type but neither
ENDJRNPF or ENDJRNAP would work. Each said the object was not of the
correct type.
Presumably that was the msg CPF7002 "File &1 in library &2 not a
physical file."
A logical file [different from the Access Paths of a logical file]
can be implicitly journaled. Implicit journaling of the logical file
can be ignored in possibly all cases; perhaps this is an exception, for
which the effects may not be desirable, yet if there is no actual
problematic effect that can be articulated [such as recovery fails],
then the effect would be a restriction, because the status of
/journaled/ remains valid. An attempt to End Journal Object (ENDJRN) is
AFaIK, also unsupported; I expect the ENDJRN command also effectively
would complain of the file type, but I suppose with a msg CPE3440
"Operation not supported."
AIUI the implicit journaling should be controlled entirely by the
database (DB) feature. After the underlying physical file objects are
no longer journaled, the implicit journaling should implicitly be
removed or reestablished to the other journal after the underlying data
has been assigned to that other journal. I can see how that effect
would be unlikely in the given scenario, up to that point, such that
until some action against the VIEW for which implicit journaling was
[again] required, the VIEW might remain journaled to the old\original;
as I do not fully understand the details about that feature of implicit
journaling of the LF, that the object is journaled when required may be
the only concern, such that to what journal is immaterial.
To get by the errors we had to delete the VIEW in the training
library and recreate it in the training library.
Was the VIEW still showing as journaled, or merely showing the
historical journaled-to information? Even if still journaled, that
apparent illogical condition might be easily ignored with no
ill-effects. Given there is no support to effect [a nonexistent]
ENDJRNLF, explicit or programmed attempts to end journaling of the LF
[for other than Access Paths] are going to fail, so easily circumvented
by simply not making that attempt.
I expect the proper outcome was, as noted above, that the implicit
journaling would have been ended; optionally journaling started again,
to the same journal as the underlying data, if\when journaling was
deemed to be required, just as had transpired when the VIEW was first
implicitly journaled. If the journal to which the LF gets journaled is
immaterial such that the latent assignment is never replaced, then
perhaps the DB feature better would have established a journal much like
those in QUSRSYS [for a moment I thought of the journals like QSQTTJRN
in QRECOVERY, but for what the implicit journaling effects, I am sure a
journal that was saved\restored as part of DR is required; thus the
choice of the journal of the underlying data].
I did not think about it until we were done but should we have done
this process using Navigator or some way using STRSQL to adjust
object journaling?
One method is to pre-create the library as a non-SQL library, and
then Start Journal Library (STRJRNLIB) to request the library function
much like the SQL COLLECTION, but preferably with a journal object name
other than QSQJRN. There is also the deprecated QDFTJRN Data Area
(DTAARA) support; I recall however, documenting support missing from the
STRJRNLIB support, and IIRC that was even something related to restore
activity. If the catalog VIEW files are required, then the
aforementioned QSQXRLF program can be used to make the non-SQL library
look and act even more like a SQL SCHEMA.
midrange.com
