×
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.
I just examined the results of a diagnostic I'd inserted into our
SQL-interface program yesterday, checking to see if the QSQCLI
activation group is present just before the call to SQLExecDirect.
It turns out that just before the call that crashes and burns, the
activation group is still there. And it's not there when I look at the
job after it locks up.
Which puts us back to the hypothesis that something else in the job has
grabbed SQL out from under me.
***
On another note: This is a child-server job, with a single persistent
connection to a single client (for the duration of the job), with an ILE
mixed-language server program launching at the top of the job, and
remaining on the call stack until the job ends. This server program runs
in a *NEW activation group, with everything it calls running in either
the same activation group, or in the default activation group. There
have been suggestions that the use of *NEW for this server program could
in some way be related to the problem.
Can anybody think of a reason why there would be any difference between
*NEW and a named activation group, for a server program that's active
for the duration of the job?
--
JHHL
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.
midrange.com
