MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2014

Re: SNDDST and multithreading



fixed

Rob, would you be willing to expand on this a little please? I went
looking in WRKREGINF and didn't find anything linked to SNDDST.

Another program is assigned to fix this issue and I'm thinking I would
rather do what you suggested.


On Wed, Dec 18, 2013 at 10:40 AM, <rob@xxxxxxxxx> wrote:

I use a command exit point program to change all uses of SNDDST, and then
it logs it also. We used to log to rip it out of code as time allowed.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Michael Schutte <mschutte369@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/18/2013 10:33 AM
Subject: Re: SNDDST and multithreading
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Thank you for the reply Brad. Just to be clear, we are not using Java to
send files from QDLS. I was just mentioning that we have other programs
that do use Java RPGMAIL. Those programs are using the IFS (not QDLS). My
thought was that if the user would have executed the RPGMAIL code
previously and then came to execute the SNDDST command, then maybe RPGMAIL
"java" was causing multiple threads to create.

So from the sounds of it, it could be both SQL and RPGMAIL. Grrr. We
do
have a program to change SNDDST to use RPGMAIL instead. I was just
curious!

Thanks.


On Tue, Dec 17, 2013 at 10:59 AM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

I think it's the Java. The multi-tread no no is because SNDDST uses
QDLS
file system which doesn't work with Java (at least I've always received
similar errors when Java tries to access a file in the QDLS file
system).

Brad
www.bvstools.com


On Tue, Dec 17, 2013 at 9:29 AM, Michael Schutte <mschutte369@xxxxxxxxx
wrote:

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/RZAHWOVEPO.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™ 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.


--
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.


--
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.



--
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.







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact