Re: SNDDST and multithreading

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.