×
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 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."
http://www.ibm.com/support/docview.wss?uid=nas2e26e874c01c4049886257b100042409f
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
worthwhile.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.