Re: SQLExecDirect throwing Pointer Not Set?

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