×
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.
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.
midrange.com
