3000 job queues - WOW - why so many
Just curious :-)
Don Brown
From: dlclark@xxxxxxxxxxxxxxxx
To: "Midrange-L" <midrange-l@xxxxxxxxxxxx>
Date: 08/12/2017 01:40 AM
Subject: Newsletter / Marketing: "Parallel Processing" Tool --
was: [WDSCI-L] Namespaces -- was: Debug slows program by a factor of 30?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
"WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx> wrote on 12/07/2017 10:00:51 AM:
http://www.easy400.net/syncjob/html/page1.htm
That's an interesting tool. Presuming that the parallel jobs are
submitted through the tool, is there a way to contact the author to ask
about an additional feature?
I ask, because I currently have a CL program that has to loop on a
call to an RPG program 600 times in order to produce all the data needed
for a consolidation process (and currently taking almost 4 hours to
complete, serially). But, each time I call this RPG program with a
different library list. Thus, each of these iterations do not share
database resources and it seems they would be an excellent candidate for
parallel processing.
However, using the above tool, I can't just submit 600 jobs and
then let the system slug it out on its own. Rather, I would like it if
the tool would accept a specification for the number of like-jobs that can
run in parallel with each other -- say, 5 at a time. Yes, I could create
a separate job queue that only allows a max of 5 active jobs, but... ;-)
We already have a plethora of job queues (> 3000) and wouldn't really
like having to add yet another job queue each time another parallel
process comes up with different active job requirements.
So, what do you guys think? Would you rather a tool control the
number of active parallel jobs in this type of situation? ...or, would
you rather have a separate job queue that controls it? Any other ideas?
Thanks.
Sincerely,
Dave Clark
midrange.com
