On 12-May-2014 09:40 -0500, Steinmetz, Paul wrote:
Chuck, Thanks for all the feedback.
A more recent followup to this thread reminded me of an unsent reply
I was composing in the past; I found this reply partially composed in my
drafts folder. I have no battery, am using a Mac with a break-away
power supply, and experience periodic [some labrador-retriever-induced]
power losses.
I'm still mystified why the MCH3601 and MCH0601 disappeared on the
4/26 run. (what changed between 3/31 and 4/26)
Too little info to guess. Assuming everything is effectively
identical, the difference could be a simple nuance in [what is in] the
memory referenced by the failing code; i.e. some defects are not [as we
called them:] "solid", because the vagaries of effectively anything
else, despite most of the code and processing being seemingly identical.
Is it possible that these are two different issues, (CPF5009,
CPF5026) and (MCH3601, MCH0601).
The latter are clearly a direct side effect of the former, but the
former may be normal. A review of both the object(s) and row(s) for the
routine name at issue, could be performed before the [potentially]
failing operation, and the QSQJRN in QSYS2 would track the activity
against those rows and any rows representing that routine name. Knowing
what the process does and seeing the pre-process snapshot and results
[esp. the "duplicate" condition] would reveal conspicuously if the "not
created" and prior effective "already exists" conditions are logged
accurately. That does not resolve the "why" of the LIC exceptions that
follow, but would hopefully establish a recreate scenario.
I IPL'd this weekend, applied all latest PTFs.
I will be running this process again on 5/28.
I agree with your statement on RCLSTG *DBXREF, also IBM no longer
recommends this a possible resolution step.
A reclaim is generally discouraged; has been for many years. However
the reclaim of the System Database Cross-Reference [DB XREF] data is
hopeless for correcting any data issues with [logical] objects that the
feature has no-hand-in processing; i.e. Reclaim Storage of the *DBXREF
would be completely illogical as an attempt to correct data that the
feature does not even track.
APAR SE45470, PTF SI41617 is a V6R1 issue, I'm not finding this for
V7R1.
I could not find the PTF cross-reference summary to find the v7r1
match to the v6r1 SI41617 for SE45470. But keyword searching found
SI41637 for SE45498 is the apparent IBM i 7.1 equivalent; but such an
old cumulative for both releases, surely that PTF is not the required
preventive [i.e. surely the PTF is already applied], though perhaps the
same origin.
<
http://www.ibm.com/support/docview.wss?uid=nas3e1013e536d68d257862577f30057fc40>
The origin for that problem is with how the routine definition was
processed in an upgrade to v6r1; i.e. the implication being, that the
potential exists for a latent issue being detected [in a later release],
and the old PTF would have to have been applied as preventive on the
install media [or possibly instead a circumvention implemented] to avoid
the issue. However the APAR SE45498 resolution suggests the code will
be more tolerant [for restore]; so possibly that either only the restore
path was made more resilient, or the duplicate\restore code path is not
resilient enough in this situation, or that APAR issue is not a match to
the issue in this topic\thread.
IBM currently has a test PTF, SI53044, for a similar issue, but not
the exactly the same. This is issue also involves IASP, which I do
not have.
From IBM: <<SNIP>>
While an issue may be detected when using iASP, and [thus possibly]
include a symptom kwd for iASP, the issue is not necessarily specific to
independent ASPs. The errors and other symptoms might imply a
similarity, irrespective of iASP use. Yet such an implication is much
poorer than an actual review of the failing situation by the dev, to
better understand the failing scenario for a known level of code and
knowing what is the current status of both the [service] program and
catalog entry when that process starts. I suppose more likely, instead
of an actual developer review, the joblog was reviewed and a possibly
"similar issue" was divulged; and that may not be helpful, except for
the dev to know that the latest code-level was installed with the most
recent recurrence :-(
midrange.com
