RE: Optimizing for Java and Tomcat (x-posted)

Read my recent posts. It really isn't difficult to set up a new subsystem. Try stuff. If it doesn't work, delete it and start over. That's one of the reasons I put all my trial stuff in a new library ... RMVLIB and its gone ... start again. If you are having trouble, go look at one of the descriptions (DSPSBSD or WRKSBSD) of the standard subsystems (QINTER, QBATCH, etc) and see how they're set up.

I studied the Work Management book very carefully when I first started on AS400 (before it was announced, actually). I've been picking up more understanding of it each time I mess with a new subsystem or job queue.

One trick, make the first pool in your subsystem description the *BASE pool, but don't route any work there. That's so the subsystem monitor job goes in the base pool. When you add another pool you have the option of specifying a size (that's a private pool known only to the subsystem) or of choosing one of the shared pools or even the *MACHINE pool. All the pool definitions are done within the CRTSBSD or CHGSBSD command.

Routing entries (ADDRTGE) set up the pool and other attributes about the job; at least those attributes that don't come from the *JOBD. In fact, there's lots of ways to pick up info from the *JOBD in the routing entry and vice versa. The easy way is to set up the routing entries just exactly like the ones in QBATCH, though you probably won't need the ones that compare for QCMD38 or QS36EVOKE or QIGC, which only leaves *ANY. The last one in the list (highest sequence number) is the default and should always be a "catch-all" like *ALL. The last one in QBATCH invokes QCMD to process the job which is fine. You could also put one in to invoke QSH and handle the submission more directly, but I haven't tried that yet. The routing entry specifies the pool identifier which is the pool id within your subsystem description and should be 2 (or higher) as 1 is *BASE as I talked about in the last paragraph.

Skip the communication entries, remote entries and workstation entries. You don't have to have autostart or prestart entries either, though I've used an autostart entry (ADDAJE) on my subsystem description to kick off Tomcat. I have a special JOBD (CRTJOBD) set up for Tomcat as autostart refers to a job description. The job description is tricked up only to set the library list at virtually empty as Tomcat doesn't use it all and a couple other minor tweaks.

If you use an autostart job, you don't really need a JOBQ, but I find it convenient to have one, especially to submit the job that ends Tomcat.

Note that the WAS (Websphere Application Server) setup does all this so WAS runs in its own subsystem. I didn't invent anything new, though I didn't know about it at the time.

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-
bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Friday, November 22, 2013 11:09 AM
To: Java Programming on and around the IBM i
Subject: Re: Optimizing for Java and Tomcat (x-posted)

On 11/20/13 3:10 PM, Dan Kimmel wrote:

First, run java in its own storage pool. There's a couple ways to do
this. I create a separate subsystem and allocate a pool to it. I
allocate either a private pool or one of the *SHRPOOLxx's. I make the
pool big enough to handle the size I specify as Xmx in the java
command.

I'm still trying to understand how to do this. I might have set up a
subsystem once, many years ago, but I don't really understand the
process, and the documentation I've been able to find so far doesn't say
much about private pools (and the easiest-to-understand tutorial I've
found so far is written in a cutesy "Wizard-of-Oz-Movie" style, and is
19 years out of date).

I haven't yet gone to the Work Management book (but I'm about to do so,
and I've heard it's not a particularly easy to understand manual).

--
JHHL

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