Re: SNDDST and multithreading -- MIDRANGE-L

Thanks, I wouldn't worry too much about it. I was just looking to see if
anyone could validate maybe from past experience. It's looking like that's
the case, that SQL is doing it. We are currently changing the program to
use RPGMAIL.

On Sun, Dec 22, 2013 at 12:59 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 17-Dec-2013 13:20 -0800, Kevin Wright wrote:

We heard of problems where SQL queries would use extra threads, then
leave those threads around to cause issues with commands or APIs
that could were not multithread capable. Like you we could not see
where we were explicitly causing a job to go multi-threaded. It may
have been something to do with a particular QQRYDEGREE value. I am
not sure whether IBM put out a PTF to get rid of the extra thread(s)
once SQL was finished with them.

I did a number of defect searches and came up empty. I figured the
more mundane origin would be that no full-close on the query cursor has
transpired to cause the query engine to terminate its extra threads;
i.e. the SQL is not finished with the system-threads that it created
previously [having overridden any restrictions per ALWMLTTHD(*NO) for an
interactive job], because the queries are still _active_ within the job,
regardless that the queries no longer may be getting positioned or
FETCHed from, and thus might be considered by the programmer\user no
longer to be active. I alluded such, in a prior reply.

However in a test on v5r3 [using a FENCED vs NOT FENCED UDF to best
ensure additional threads] I found that from STRSQL with the
implementation of the function being to open the TABLE QSQPTABL in
QSYS2, that file remained open to the *DFTACTGRP and only a SIGNOFF will
effect the close... and there were some threads pending. I presumed
before testing, that if the UDF was defined to run in a named
activation, I could issue RCLACTGRP to effect the termination of those
threads. Turns out though, that the threads disappeared automatically
without reclaiming the activation; this was also when using STRSQL, thus
invoked from *DFTACTGRP. I have _still not tried_ running the query
from a named activation whereby the UDF runs in either a separately
named activation group or in *CALLER.

I will be unable to followup anytime soon, and I am unlikely to setup
any followup reminder. If I see more recent followup replies, perhaps I
will remember to come back to this.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.