× 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 17-Jan-2012 08:58 , James Lampert wrote:
CRPence wrote:
On 16-Jan-2012 15:23 , James Lampert wrote:
We have a customer installation that's doing something I've
never seen before: SQLExecDirect is throwing a Pointer Not Set
exception at:
From program . . . . . . . . . : QSQCLI
From library . . . . . . . . : QSYS
From module . . . . . . . . : SQLED
From procedure . . . . . . . : SQLExecDirect
From statement . . . . . . . : 12161

with what looks to be a perfectly mundane SQL SELECT.

Does anybody have any idea what could cause that?


A defect.? What are the full message details including the release?

Apparently that is the symptom ["to", not "from", for an exception]:
msgMCH3601 T/QSQCLI Tm/SQLED Tp/SQLExecDirect stmt/12161

Actually, the F9 on the message shows the above for both "To" and
"From."

Yep. And while there is no requirement for anyone to know, there may be some benefit to know, that... The "convention", when describing a symptom, is to describe the problem according to the context. For a "machine" exception within the program, the program\procedure is the recipient of the error rather than the sender of the message, irrespective of the presentation by the Display Message panels :-)

Thus the "convention", if properly followed would never have any mention of the "from" in the symptoms for the APAR. So searching for symptom keywords strings that do not follow the conventions might not locate a match. The APAR SE50301 uses "OSP-DB-MSGMCH3601-T/SQLED" [missing the much more relevant and specific TP/SQLExecDirect]. However FWiW that APAR could be found more generically searching just those procedure, program, and module names because [although not typical in my experience] the developer left an effective F6=Print form of the output in the APAR text.

And the thing is, it works just fine when the same front-end program
is called in the "command-line test" mode I put into it, but fails
when called from our CRM product.

The two versions of the APAR have the identical text including the comment suggesting that the "exception may be seen if another program has allocated the CLI environment." Thus if the CRM product utilizes the CLI, then that is a high probability match... even with the large discrepancy in the statement numbers.

This particular customer has also plugged some rather strange library
list initialization (possibly doing other things) into one of our
exit-hooks, and I'm wondering if any of what they're doing could be
driving SQLCLI insane.

Maybe allocating\initializing the SQL CLI there, if not done by the CRM product.

Regards, Chuck

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.