OS/400 ships with WebSphere Standard Edition, which provides support for the server- side Java capabilities of JavaServer Pages (JSPs) and servlets. But I must admit I haven’t been faithful to IBM. I have to confess that I’ve been Tomcatting around; I’ve been going out on WebSphere and fooling with other Web application servers. Why the disloyalty to IBM? Why am I no longer true to Blue? For one, WebSphere 3.0 (the version that now ships with OS/400 V4R4 and V4R5) is difficult to install and difficult to configure. For another, whereas WebSphere is bundled with OS/400, it is a chargeable product for most other platforms, and I’ve found an open source Web application server that will work on almost any computer that runs on electricity.

The name of this open source Web application server is the Apache Software Foundation’s Tomcat. That’s the same open source organization whose Web server, the Apache Server, is running on 60 percent of all servers in the world (according to the Netcraft Web Server Survey at www.netcraft.com/survey). Tomcat is quickly becoming a dominant player in the Web application server market as well. When Tomcat first became available, however, it was thought of as merely a reference implementation of a Web application server (that is, one to be used for proof-of-concept applications). But more and more mid-to-high-end Web sites are using Tomcat as their production Web application server. Webhelp.com, for instance, uses Tomcat to service over 10 million JSP/servlet transactions per day. Unless your site gets more hits than that, you might consider trying Tomcat out yourself. This article covers how to install, configure, test, and tune Tomcat on your AS/400.

Installing Tomcat

To install Tomcat on your AS/400, first download to your PC the jakarta-tomcat.zip file from the Jakarta Project Web site (http://jakarta. apache.org). The current release build (at press time) is Tomcat 3.1, which you can download from Jakarta’s Binary Downloads page (http://jakarta.apache.org/downloads/binindex.html). You can use WinZip to install Tomcat on your PC, but this article discusses Tomcat installation for the AS/400. You’ll need to then upload the jakarta-tomcat.zip file (using FTP or a similar utility) to a directory

on your AS/400 Integrated File System (AS/400 IFS). To unzip Tomcat on the AS/400, you’ll need to use Java’s JAR tool from the Qshell Command Entry screen. Start Qshell with the QSH command, change your current directory to the IFS root, and invoke the JAR utility:

cd /
jar xf /where/ever/you/put/jakarta-tomcat.zip

The x option says to extract, and the f option says the compressed file name is to follow, so be sure to qualify the exact location of the jakarta- tomcat.zip file. Note that Qshell is thread-based, so its command screen is input-capable, even while the extraction process is running. The extraction process may take two or three minutes, but you’ll know it’s complete when you see a dollar sign ($) underneath the JAR command. The extraction process creates a directory called Jakarta-tomcat underneath your working directory, which should be directly under the AS/400 IFSRoot (/) directory if you used the cd / command I have specified.

To quickly prove to yourself that Tomcat was installed, change the working directory to jakarta-tomcat and list the files and directories within by using the ls command:

cd Jakarta-tomcat
ls

You should see a list of six directories (bin, conf, doc, lib, src, and webapps), as well as one file (LICENSE).

Tomcat requires no configuration unless its default use of ports 8080 and 8007 is in conflict with one of your existing TCP/IP server applications. The ports are set in a file called server.xml in Tomcat’s conf directory. The easiest way to modify that file is to use the Edit File (EDTF) command (which has been available only since V4R4):

EDTF ‘/jakarta-tomcat/conf/server.xml’

If you scan for the string port, you’ll find the two places the ports are set. Make the change, hit F3 to exit, and your Tomcat server will be configured for the new port.

Starting Tomcat

Tomcat ships with both UNIX- and Windows-style scripts, but for the AS/400 you’ll need to create an OS/400-specific Qshell script file, such as the one shown in Figure 1, which is available at www.midrangecomputing. com/mc for download as a file called tomcat400.sh. Note that the script begins by setting the QIBM_MULTI_THREADED environment variable to true so it can appropriately “spawn” the Tomcat server application. It then creates an environment variable to qualify Tomcat’s home directory. Note that the s option of the export command says the environment variable is available to subprocesses. The script then saves the current CLASSPATH before it adds Tomcat’s JAR files, which contain the all-Java code that runs the server. The script then adds application-specific JAR files. Most AS/400 sites will, at the very least, be adding the JAR file called jt400.jar, which is available after the installation of the AS/400 Toolbox for Java program product (5763-JC1). Finally, Tomcat is started with java, the Java Virtual Machine (JVM) command. Note that the funny little ampersand (&) that trails the java command is required to start Tomcat as a thread-based subprocess.

Once you have your OS/400-specific Tomcat startup file ready, you can invoke it with the following Submit Job (SBMJOB) command:

SBMJOB +
CMD(QSH CMD(‘/jakarta-tomcat/bin/tomcat400.sh’)) JOB(tomcat)

If you get an Address already in use error, your Tomcat default ports may already be in use. If this happens, change the port numbers, as specified in the Installing Tomcat section of this article.

Because Tomcat is a never-ending server application, it should not be run interactively. You also need to consider what subsystem Tomcat should run under. When playing with Tomcat, you might just let it run as a low-priority batch job. Later, however, you might want to run it with a much higher priority, since Web applications are, after all, interactive.

Once Tomcat is successfully running, you should be able to access it from your Web browser by qualifying your AS/400’s domain name or IP address, followed by a colon and Tomcat’s port number (8080, if you didn’t change it in your server.xml file). You should now see the Tomcat home page, as shown in Figure 2. I encourage you to try the example JSPs and servlets (be sure to check out their source code). If you want a quick way to try out your own JSPs and servlets, simply copy your JSP, HTML, and image files to /Jakarta-tomcat/ webapps/Root, then copy your servlets and JavaBeans to /Jakartatomcat/ webapps/Root/web-inf/classes.

All good things must come to an end, and so, too, must your Tomcat job. To end Tomcat, you need to invoke a Qshell script, such as the one shown in Figure 3 (available for download as a file called endtomcat400.sh). This script runs quickly, so go ahead and run it interactively from a command line:

QSH CMD(‘/jakarta-tomcat/bin/endtomcat400.sh’)

I was going to write a couple of OS/400-style commands that invoke my two Qshell scripts, but if you don’t have anyone in your shop who knows how to write commands, you may as well just run Tomcat from Linux or Windows NT.

Performance Tuning

Note that the first time you run any of the examples, you’ll experience a lag time of a few minutes. That is the time OS/400 must take to run the Create Java Program (CRTJVAPGM) command over Tomcat’s JAR files. The problem with this automatic process is that the CRTJVAPGM default optimization level is 10, but optimization 10 is the slowest. I suggest you run CRTJVAPGM manually and set the optimization level at 40 (that’s what WebSphere’s JAR files are automatically set to).

Each of the following commands will properly optimize Tomcat:

CRTJVAPGM CLSF(‘/jakarta-tomcat/lib/servlet.jar’) OPTIMIZE(40)
CRTJVAPGM CLSF(‘/jakarta-tomcat/lib/jasper.jar’) OPTIMIZE(40)
CRTJVAPGM CLSF(‘/jakarta-tomcat/lib/webserver.jar’)

OPTIMIZE(40)
CRTJVAPGM CLSF(‘/jakarta-tomcat/lib/xml.jar’) OPTIMIZE(40)

You might want to submit those CRTJVAPGM commands to batch, as they may take 5 to 10 minutes each to complete.

This Means WAR

The benefits of Tomcat go beyond price and robustness; it also includes support for Sun’s Java Servlet API Version 2.2 and JavaServer Page 1.1. Few commercial Web application servers support Servlet 2.2, including WebSphere. The best part of the Servlet 2.2 API is the Web Archive (WAR) files. Let me explain. One of the biggest problems with Web applications is deployment. Often the test and debug platform and runtime environment are

different from production, and every Web application server handles deployment differently. The Servlet 2.2 solves this dilemma with WAR files.

WAR files are basically JAR files, except that they contain everything (JSP, servlets, HTML, XML configuration files, images, and the rest) required to run an application. To deploy, all you need do is move the WAR file to the /Jakartatomcat/webapps directory and modify Tomcat’s configuration file to qualify the new WAR file. (You don’t have to extract the WAR file; the application runs right out of the compressed file.)

Debugging JSPs and Servlets

IBM’s VisualAge for Java (VAJ), Enterprise Edition, provides a great debugging environment for JSPs and servlets, but VisualAge for Java, Enterprise Edition, is a costly product. However, because Tomcat ships complete with its source code (it has to, it’s open source), you can easily set up your entry-level Java integrated development environment (IDE) so that you can step through your Java servlets. (This also means you can step through the Java servlets code generated from a JSP.) There are two Web articles that show how to set up Borland JBuilder Foundation and VisualAge for Java, Enterprise Edition, for servlet and JSP debugging: “Apache Tomcat Servlet and JavaServer Pages Development with JBuilder Foundation,” by Debbie Carson and Ken Chan (http://community.borland.com/article/0,1410,22057,00. html), and “Apache Tomcat 3.1 Final Release Servlet and JSP Development with VisualAge for Java,” by Sheldon Wosnick (http://www7. software.ibm.com/vad.nsf/Data/Document2390?OpenDocument).

Basically, all these documents tell you to do is add Tomcat’s JAR files to your IDE’s classpath and then add the org.apache.tomcat.startup. Tomcat class to your IDE’s project. You’ll also have to add a parameter to wherever your Java IDE allows you to set the Java Virtual Machine property options:

-Dtomcat.home=C:whereeveryouput omcat

Then add the servlet you wish to debug to your project and set breakpoints. With all that done, you simply start the Tomcat class in debug mode from your IDE. I’ve set up a Tomcat test environment with JBuilder Professional 3.0, and you should be able to do the same with your favorite IDE.

Open Up to Tomcat

Yes, WebSphere probably scales better than Tomcat, but not that I could easily tell. You see, I downloaded another open source product from the Apache Software Foundation called JMeter. JMeter is an all-Java product that allows you to stress-test Web sites. A quick, simplistic, and admittedly unscientific test showed that a couple of simple JSP data- access routines performed just as well with Tomcat as with WebSphere (although that was before I “tuned” Tomcat’s JARs). Performance issues aside, Tomcat is very simple to install and configure. You don’t have to worry about HTTP configuration (Tomcat bundles its own HTTP server). You don’t have to deal with WebSphere configuration from an over-sized NT workstation. And, you have the latest and greatest of the servlet and JSP standards.

REFERENCES AND RELATED MATERIALS

• Apache Software Foundation: www.apache.org

• “Apache Tomcat 3.1 Final Release Servlet and JSP Development with VisualAge for Java,” Sheldon Wosnick, www7.software.ibm.com/vad.nsf/Data/ Document2390?OpenDocument

• “Apache Tomcat Servlet and JavaServer Pages Development with JBuilder Foundation,” Debbie Carson and Ken Chan, community.borland.com/article/ 0,1410,22057,00.html

• Jakarta’s Binary Downloads: http://jakarta.apache.org/downloads/ binindex.html

• Netcraft Web Server Survey: www.netcraft.com/survey

• The Jakarta Project: http://jakarta.apache.org

# save the current classpath
export QIBM_MULTI_THREADED=Y

export -s TOMCAT_HOME=/jakarta-tomcat

# save the current classpath
set OldClassPath=$CLASSPATH

# add Tomcat's Jar files to the classpath
set CLASSPATH=.
export -s CLASSPATH=$CLASSPATH/classes
export -s CLASSPATH=$CLASSPATH:$TOMCAT_HOME/lib/webserver.jar
export -s CLASSPATH=$CLASSPATH:$TOMCAT_HOME/lib/jasper.jar
export -s CLASSPATH=$CLASSPATH:$TOMCAT_HOME/lib/xml.jar
export -s CLASSPATH=$CLASSPATH:$TOMCAT_HOME/lib/servlet.jar

# add application-specific Jar files to the classpath
export -s
CLASSPATH=$CLASSPATH:/QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar
export -s CLASSPATH=$CLASSPATH:$OldClassPath

# start Tomcat
echo Using classpath: $CLASSPATH
java -Dtomcat.home="$TOMCAT_HOME" org.apache.tomcat.startup.Tomcat &

# reset the classpath to its original state
export -s CLASSPATH=$OldClassPath

Figure 1: To run Tomcat on your AS/400, you’ll need an AS/400-specific startup script.

Figure 2: Once you submit the Tomcat script to batch, you should be able to access it from your Web browser.

# set Tomcat's home directory
export -s TOMCAT_HOME=/jakarta-tomcat

# save existing classpath
export -s cp=$CLASSPATH

# add the Jar files required to end Tomcat to the classpath
set CLASSPATH=.
export -s CLASSPATH=$CLASSPATH/classes
export -s CLASSPATH=$CLASSPATH:$TOMCAT_HOME/lib/webserver.jar
export -s CLASSPATH=$CLASSPATH:$TOMCAT_HOME/lib/xml.jar

# end Tomcat
echo Using classpath: $CLASSPATH
java -Dtomcat.home="$TOMCAT_HOME" org.apache.tomcat.startup.Tomcat-
stop

# restore classpath to its original value
export -s CLASSPATH=$cp

Figure 3: To end Tomcat, run a script that “gently” brings it down.