Default depends on which jobq and which subsystem. QBATCH *JOBQ, for instance, is 1-wide by default. QUSRNOMAX is *NOMAX by default. Many admins open up QBATCH to 4-wide. QBATCH feeds the QBATCH subsystem, which, I've found, is a lousy place to run java as java paging interferes with normal batch system paging and neither runs well.
QBATCH was configured 1-wide origially so you could throw a bunch of jobs on the queue and be assured that one wouldn't start until the one preceeding it in the queue had finished. Useful when each job depends on the results of its predecessor. That's the way we designed batch jobs 20 years ago.
Restricted width also helps manage demand on memory and processor. It's useful for that aspect, as well.
Now we have all these service jobs that load in memory and wait for an event like a database request or a html page request. QSYSWRK and QUSRWRK were designed for those.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thorbjørn Ravn Andersen
Sent: Friday, February 01, 2013 9:55 AM
To: 'Java Programming on and around the IBM i'
Subject: RE: RUNJVA redux
I know that the i is very capable of doing a lot of work with a lot of jobs, so I may very well be wrong.
I just happened to run into - a long while back when my beard was less grey
- a situation where this was a bottleneck.
Am I right when saying that the _default_ configuration of this job queue thing is four slots, and you need a system administrator to change it?
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Dan Kimmel
Sent: 1. februar 2013 15:56
To: Java Programming on and around the IBM i
Subject: RE: RUNJVA redux
Yeah, I'm confused by that, too. I run java either in QUSRWRK (QUSRNOMAX
*JOBQ) or I build my own subsystem with *NOMAX as the number of jobs and *NOMAX as the number of jobs from the jobqueue. I build my own subsystem for servers like Tomcat as I've found a dedicated memory pool yields performance improvement. I can run any number of java jobs (with QSH, even) without tying up any scarce resources other than processors and memory.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jim Oberholtzer
Sent: Friday, February 01, 2013 5:40 AM
To: Java Programming on and around the IBM i
Subject: Re: RUNJVA redux
Job Slots? Clearly we know the IBM i can run many hundreds of thousands of jobs, so I am curious about the term and how it applies? Where is the limitation on jobs to default to four?
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
On 2/1/2013 4:51 AM, Thorbjørn Ravn Andersen wrote:
There is one distinct advantage of using the RUNJVA command instead of
"java -cp ...". The latter require QSH for interpretation which in
turn take up a job slot. This is important on the i because the
default setup is (to my
understanding) only four such slots, hence taking up a valuable resource.
-----Original Message-----
From:java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Kelly Beard
Sent: 31. januar 2013 20:28
To: java400-l
Subject: RUNJVA redux
Thorbjorn's solution appears to be the correct one. If I specify
CLASS(Balancer) instead of CLASS(Balancer.jar), it works fine. I'm
not really interested in use the RUNJVA command, but wanted to learn
the
"other"
way of running Java on the 400.
So, thanks to everyone for their contributions of notes about the
idiosyncrasies of RUNJVA.
--
Kelly Beard
--
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/java400-l.
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/java400-l.
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/java400-l.
midrange.com
