Re: SNDDST and multithreading

On 03-Jan-2014 12:20 -0800, Jerry Draper wrote:

After we upgrade to V7R1 we found that a number of old routines that
used a combination of this will err out (see error below):

≥ CPYTOIMPF
≥ RUNSQLSTM
≥ QSH
≥ CHGDOCD
≥ CPYTOIMPF (failure occurs here)

A Retry after some minutes allows the job to complete normally.

So the failing request apparently uses the /QDLO file system [as inferred from Change Document Description (CHGDOCD) that precedes it, and the messages noted later]? If so, then using the root file system to output to a stream file (STMF) vs output to a *DOC [in the old-style 8.3 PC document folder file system] would avoid that error... and avoid all the other restrictions and requirements of the DLO vs STMF.

If we put a DLYJOB DLY(120) after the RUNSQLSTM it completes normally.

Because a hard-coded wait is both possibly excessively long and possibly too short avoid encountering the exception, it is IMO a poor implementation as an attempt to circumvent. A routine that polls on a shorter timed-wait, each time interrogating the existence of secondary threads, would seem a more timely /solution/.

Of course a true /solution/ would probably require a QAQQINI option to tell the query processor not to implement that way; i.e. a means to tell the Query Engine to expunge the secondary [system] threads when the query closes, instead of them hanging about [for an unstated amount of time] awaiting possibly more work.

The error has to do with the multi-threaded environment implemented
in V7R1. There is no "fix" for this. Welcome to multi-threading.

Apparently the following is some document\reply sent to you, in response to an inquiry.? Perhaps from IBM? Is there an IBM Technical Document to document the new behavior? An APAR [there should be one; if that response was from a PMR reported to IBM, demand they open an APAR so the /closure/ of the APAR is a clear indication both of their awareness of the issue and their response to customers about what was the resolution]. An entry in the Memo to Users (MTU) for the IBM i 7.1? If documented anywhere by IBM, hopefully with the source-code for an awaitQueryThreadsNoMore() routine... or identification of the PTF that provides the new command to Delay for Query Threads (DLYQRYTHD) for as long as the WAIT() parameter suggests before the command terminates issuing an exception that the condition was not met prior to the allowed\specified wait-time being exceeded.

Jerry

When running SQL or using user defined functions, the system will
often spawn multiple threads to complete the request. At R710, these
threads are left open longer to improve the performance of future
calls to the same function or statement. This can cause failures if
the job the runs any function or command that can not be ran in a job
with multiple threads. Some examples these errors include:

msgCPE3524 Message . . . . : Function not allowed.
Cause: Function is not allowed in a job that is running with
multiple threads.
msgCPF180B Message . . . . : Function &1 not allowed.
Cause: Function &1 is not allowed in a job which has multiple
threads.
msgCPFA0D4 Message . . . . : File system error occurred.
Error number 3524

Since they were written in symptom kwd form, adding: errno3524 and rc3524 for return code, and the non-kwd form for each message CPE3524 CPF180B CPFA0D4 making them capable of being searched otherwise.