Hi Michael,
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.
Regards,
Kevin Wright
Developer, LPC
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Schutte
Sent: Wednesday, 18 December 2013 2:30 AM
To: Midrange Systems Technical Discussion
Subject: SNDDST and multithreading
Every month we are getting an error from SNDDST saying that it cannot be
ran in jobs with multiple threads. I get that this command cannot run
with multiple threads. But I curious on why we are getting multiple
threads in an interactive session.
The program trying to use this command is vendor code. All of their
code is written in RPG3 and CLP running in the default activation group.
We now own the code and as we make changes to the code, we convert to
RPGLE. We have created service programs, some with named activation
groups, others with named activation groups. We have also introduced
SQLRPGLE into some programs (FYI, when we make changes to the vendor
code, we move to a new library higher in the LIBL, we leave the original
code alone, just our decision to do that). Side note, all programs
called interactively is called by a menu program written in RPG3 by the
same vendor, as we convert the called programs from RPG3 to RPGLE we
sometimes add HSPEC
actgrp(*CALLER) other times we do not. When using *CALLER, it's my
understanding that the program run in the default activation group. Not
sure if this matters to anyone trying help me with this situation.
I've been reading articles on the web about multithreading (new concept
to me). I remember once reading that to start a new thread, the program
has to specifically call the spawn routine. I'm certain that none of us
at this shop has done this in any programs (lack of understanding being
the biggest hurdle). I've also read that Only batch immediate jobs and
prestart jobs provide multithread-capable support here:
http://publib.boulder.ibm.com/html/as400/v4r5/ic2924/index.htm?info/RZAH
WOVEPO.HTM
But that's documentation for V4R5, we are currently on V7R1. But if this
is still the case why are our interactive jobs spawning multiple
threads.
Unfortunately, I do not have any job logs to include in this email,
however as I recall the error message was CPFA0A8. Operation not allowed
in a job running multiple threads.
I also came across this website. Multithreaded programs in Java
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=%2Fcom.ibm.
mq.doc%2Fja11160_.htm
"The Java(tm) runtime environment is inherently multithreaded."
So I can see where this could be our issue. Some new emails that we
send out are being sent using RPGMAIL. RPGMAIL uses Java. So if the
user did something to send out an email, I can see this being our
culprit. But there's only one program that I recall that gets sent
using RPGMAIL and I know that it hasn't been sent because I am copied on
it. All other RPGMAIL emails are sent from batch job that are submitted
from the Job scheduler and therefore wouldn't have an effect on any one
interactive session.
This doesn't happen for all users, just a select few. The ones that get
the error are different from month to month.
The boss started asking why has this just started. The truth is we
really don't know if it just now started to happen as users used to
ignore these kind of messages. As far as they were concerned the
program completed successfully because accounts receivables had
generated an invoice (but no email was sent).
But if this is new what could be spawning the multiple threads? Is it
the SQL, Activation Groups, or is the Java?
Thanks in advance.
--
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.
midrange.com
