MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » May 2014

Re: CPF5009 , CPF5026, SQL9015 , MCH3601, MCH0601



fixed

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 :-(






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact