On 08 Mar 2013 06:43, Jeff Crosby wrote:
A recreate did fix it. We're on 7.1 with TR6 "staged" to be applied
tonight (What? Nothing else to do on a Friday night?)
The escape message from the joblog:
<ed: rewritten as a symptom string>
msgCPF426A RC2 F/QQQUDFHL FM/QQQUDFHL FP/SIGNALUDFERROR stmt/8801
T/QSQRUN3 TM/QSQOPEN TP/FULL_OPEN stmt/36556
And the [IMO poorly formed but at least somewhat reasonable] symptom
string from the APAR SE54837:
"OSP-DB-OTHER-T/QSQRUN3 X/36556-MSGCPF426A RUNNING SQL PROCS
RECEIVES ERROR MSGCPF426A F/QQQUDFHL X/8801 T/QSQRUN3 X/36556."
It is followed in the joblog by diagnostic SQL0204 that the service
program was not found.
symptoms: msgSQL0204 -204
Overlooking the obvious flaws in the IBM-provided version of the
symptom string, the error in the quoted text that I had /rewritten/ as
symptom string, looks like a highly probable match to the symptom string
of the APAR linked above. Whether the other details of the that
somewhat generic error are a match is unknown; and also unknown is how
well the APAR describes the actual possible origins and scenarios in
which the problem [that they will be correcting] exists currently.
Unfortunately there is no PTF according to that link. While there is
a link from that page to "Notify me when this APAR changes", the more
appropriate route IMO is to open a PMR with IBM. I am not sure if those
APAR tracking requests are counted as Interested-Parties for a fix. But
as the IP count grows [from actual PMRs tracking resolution to an APAR],
the service\support group gets feedback just how pervasive an issue is.
But IMO the PMR should not be merely "I want that PTF", but some
confirmation that the issue is the same; e.g. the error says "after a
power failure" but if there never was a power failure in this instance,
there is good reason to reject that APAR without some assurance that
there are other possible origins... and if so, a hint offered that the
APAR should be corrected to be less specific about origins is probably