× 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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.