On 9/7/17, 2:43 PM, Christopher Schultz wrote:
It sounds like James H.H. Lampert may be able to help you with your
problem. He's been pounding his head against his AS/400 environment
I finally get a chance to talk about something I know, rather than beg
for help about something I don't know!
(And it's not necessary to use my middle initials when referring to me,
so long as you leave out both of them. It's when people use one "H" and
not the other that irritates me.) ;-)
Just seeing "Tomcat" and a reference to an IBM Midrange box was enough
to catch my attention.
Everything I've come up with is based on the instructions to be found at
(or <https://tinyurl.com/yc3a7k5m> if you prefer). It's currently an
extremely slow-loading page.
What you want to do is go to the relevant download page at
tomcat.apache.org (so far, I've ONLY run Tomcat 7 on IBM Midrange boxes,
not earlier or later versions), and download the ZIP file (not the tar.gz).
Once you have it, figure out where you're going to put it in the IFS,
and FTP the ZIP file into that directory.
Go into QSHELL, and navigate to where you put the ZIP file, and unzip it
using Java's JAR command. (e.g., "JAR -xf apache-tomcat-7.0.81.zip")
Once that has completed, exit QSHELL. You might want to rename the
Tomcat directory to something less cumbersome (our installations rename
it to simply "tomcat")
If you're also looking at the web page, you should see a part about
modifying catalina.sh, to force "os400" to "true." You can safely ignore it.
Now, to run Tomcat on an IBM Midrange box in any kind of meaningful way,
you need to set up a CL program that will find the JVM, set up the
environment variables, and launch the thing; it's simply not practical
to do it any other way. The web page gives one very out-of-date version,
based on running a very old Tomcat under a very old JVM that you
probably don't have.
Our CL program, because we install it on customer boxes, is somewhat
proprietary in nature, so I won't give you all of the source, and it's
also fairly complex, checking for the existence of every JVM we have run
Tomcat 7 under, and also every JVM we believe is reasonably likely to
support Tomcat 7. It also allows us to launch Tomcat in a specific job
queue, so it runs in a specific subsystem, and to specify minimum and
maximum heap space (subject to the limitations of the JVM)
In our STRTOMCAT CL program, we start by building up a CL variable,
"&JAVAOPTS," that contains certain important Java options. As of just
over a year ago, it includes:
and -Xms and -Xmx options with the desired heap space parameters.
Next, it looks for a suitable JVM. Currently, the JVMs we look for, in
the order we look for them, are:
Once we've found one, we ADDENVVAR ENVVAR(JAVA_HOME) with the full
pathname of the JVM and REPLACE(*YES).
We also do an ADDENVVAR ENVVAR(CATALINA_HOME) with the full pathname of
the Tomcat directory (including the Tomcat directory itself!) and
And we do another ADDENVVAR, this time
ADDENVVAR ENVVAR(JAVA_OPTS) VALUE(&JAVAOPTS) REPLACE(*YES)
Finally, with everything else set up, we
(omitting the JOBQ parameter if we're using the default job queue for
the job description).
SBMJOB CMD(QSH +
CMD('/<Tomcat path>/bin/startup.sh')) +
JOB(CATALINA) JOBD(<whatever>/<whatever>) +
JOBQ(<whatever>/<whatever>) INLLIBL(QGPL +
QTEMP) CPYENVVAR(*YES) ALWMLTTHD(*YES)
Obviously, you will want to use some combination of job description and
job queue that won't put Tomcat into a one-job-at-a-time batch queue.
But just as obviously, you need to submit it as a batch job, because
otherwise, it's going to sit there, tying up your terminal session.
We have also done a similar ENDTOMCAT CL program, that goes through much
of the same rigmarole to select a JVM and set up environment variables,
and then submits "shutdown.sh" as a QShell batch job, and then sits
there, checking for the presence of a CATALINA job, and if it doesn't go
away within a reasonable amount of time, it then abends the CATALINA job.
Note that the CATALINA job doesn't really do a whole lot; the actual
Tomcat server runs in a job called QP0ZSPWT, that is somehow chained to
the CATALINA job. When one job dies (either naturally or forcibly), the
other follows immediately.
James H. H. Lampert
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org