I don’t know when it first started. It wasn’t anything sudden or drastic. Recently, I noticed that my AS/400—a 9406-500—which seemed so fast when compared to the 9406-E35 it replaced, had started to become sluggish in a fashion that could only be called arthritic. Jobs that used to complete so quickly just a few years ago seemed to take an interminably long time to finish. Although I thought the AS/400 was performing the same tasks now as it did then, I began to realize that the demands placed on the machine have been incrementally increasing over time.

The last straw for this particular AS/400’s performance was my company’s decision to start using the WebSphere Application Server—in conjunction with the HTTP Server for AS/400—to create applications for use on my company’s intranet. I knew I was in trouble when the IBM-supplied HelloWorld servlet took over a minute to display its reassuring Hello World in my browser. Subsequent attempts to improve performance, as suggested by IBM’s documentation and others, provided only slight relief. It soon became apparent that the only solution to this conundrum was some additional processing power. Fortunately, a new AS/400 Model 820 (or whatever they’re calling it now) is in my company’s near future, so my machine’s performance problem will be solved in quintessential IBM fashion—by throwing money at it. However, until the machine arrives, I still need to develop and test servlets.

Don and Tomcat Step In

As I sat in my office contemplating my options, I checked my email and was delighted to find a message from Don Denoncourt, Midrange Computing’s resident Java expert.

Don and I had earlier discussed my servlet performance problem and he made some suggestions, one of which was to replace the WebSphere product with something a little lighter. He suggested that I use an open-source server known as Tomcat, and his email included some comments about how to run it on an AS/400. I read his notes and considered my next move. Suddenly, I had one of those forehead-slapping “Duhhh!” moments and realized that, with the addition of Tomcat, I had everything I needed for AS/400 development work on my laptop computer.

If you want to access your AS/400 data from a Web server but you find your AS/400 is a little short in the MIPS department, this article is for you.You’ll see how I used open-source software to solve my immediate shortage of CPU power and how the same setup can be used as a long-term solution for your shop. If you have read any of my other articles, you know that I’m a great believer in open-source software. IBM does have offerings for Intel-based computers that would certainly satisfy the requirement of off-load

processing from my company’s AS/400s. However, for the purposes of this article, I will concentrate on what you can download and use without any strings attached. Though my focus is on using my favorite open-source operating system—Linux—the software and techniques described herein can be used on that other operating system as well. [Editor’s note: Barry is referring to Microsoft Windows NT/2000 here, but, being a Linux evangelist, he refuses to acknowledge that product.]

In addition, these techniques may also be fully portable to OS/400 when IBM completes its port of the Apache server to OS/400 V4R5. Don Denoncourt recently detailed how to install the Tomcat Web application server inside OS/400 and how to use it as a replacement for WebSphere Application Server, Advanced Edition (see “Tomcat for the OS/400:

An Open Source Web Application Server,” Don Denoncourt, Midrange Computing, December 2000). Once Apache is fully implemented on the AS/400, you may be able to duplicate my MIPS-saving solutions inside the black box. So, in the next year, you’ll be able to use my Linux-Apache-Tomcat development environment (using OS/400 data) as a MIPS-enhancing replacement for your HTTP Server for AS/400-WebSphere environment or as a development environment to create applications that can run in a comparable Apache-Tomcat Web environment on your OS/400 V4R5 machine.

Parts Is Parts

To begin, you’re going to need some sort of PC to configure as your server. What you will need depends upon two things:

• What you plan on doing with the machine concurrently with the Web/servlet server

• What operating system you’re going to use I use an IBM ThinkPad 770 with 128 MB of RAM and a 233 MHz Pentium processor. I use it as my primary development platform, for 5250 access to the AS/400, and for surfing the Web. It functions very well in these roles. For a standalone server with moderate traffic, a similar configuration will perform quite nicely. The requirements for a machine capable of higher traffic would certainly include a SCSI subsystem and some additional RAM since these items give you the greatest bang- for-the-buck for your performance dollars.

If you’re going to assemble this computer from parts, you’ll want to check the hardware compatibility list of your target operating system to ensure that the components you assemble are compatible. The Linux compatibility list is available in various places. If you’re going to be using a specific Linux distribution, you should check out the appropriate Web site for that distribution. The distribution I use, Red Hat, provides its compatibility list on the Red Hat Web site: www.redhat.com/support/hardware. Since all distributions are using the same kernel, you can find a generic list at www.linuxdoc.org/HOWTO/HOWTOINDEX/hardware.html. Microsoft’s hardware compatibility list is located on its Web site at www.microsoft. com/hcl/default.asp. The assembly of your machine is well beyond the scope of this article. I’ll leave the installation instructions for your selected operating system to its documentation. One last thing: You’ll need to have root or system administrator privileges on the box on which you will be working. You will be changing some of the files, and most of the directories that you’re going to load software into require privileges that exceed that of a normal user.

Native Linux HTTP Server

Although there are a number of Web servers available for the various platforms, the hands- down favorite is the open-source Web server, Apache. Apache has the lion’s share of the server market on the Internet and IBM has even ported it to the AS/400. Therefore, it’s a safe bet for your PC-based server. If you’re going to use Linux as your operating system, you’ll find it included with any of the standard commercial distributions such as Red Hat,

SuSE, Debian, and all of the others. Red Hat typically includes the HTTP server as part of all but the most restrictive installation selections. If you’re using Windows, or if you want to ensure that you have the latest version of Apache, you can find what you need at the Apache Software Foundation Web site, www.apache.org. To download the software, click on the Apache Server link. The subsequent page will provide everything you need, from the installation instructions to the documentation. Once you’ve installed the server, be sure to test it as described in the installation documentation to ensure that it’s working properly before you proceed. In the case of Red Hat, you’ll know if you’ve been successful by first pointing your browser at your own machine—that is http://localhost. If you get a page titled Test Page for Red Hat Linux’s Apache Installation (Figure 1) proclaiming It Worked,
you’re in business.

No Decaf Available

For this project, you’re going to need a Java Development Kit (JDK). Moreover, with Linux or Windows you now have many choices. Sun Microsystems (www.java.sun.com) and IBM (www.ibm.com/java/jdk/index.html) provide JDKs for both operating systems. In addition, the Blackdown Organization (www.blackdown.org) ports Sun’s JDK to Intel- based Linux through version 1.1.8. (Sun is producing post-1.1.8 for Linux.) Personally, I use the Blackdown port of version 1.1.7b on my laptop simply because I’ve had great success with it. I suggest that you visit each of these locations and determine for yourself which solution seems to fit your particular situation.

Keep in mind a few things when making your decision. First, JDK 1.2 was mostly the integration of JDK 1.1 and Swing (the GUI component of Java). Since the browser is the graphical interface for servlets, there isn’t much to be gained in choosing JDK 1.2 over JDK 1.1. In fact, the AS/400 currently supports version 1.1.8 since it doesn’t have a native graphical interface. Second, avoid the temptation to download the Java Runtime Environment (JRE) instead of a JDK. On a dial-up connection to the Internet, the JDK download will take longer than the JRE download because of its larger size. However, development is impossible with a JRE as JREs do not provide the requisite Java byte code compiler. Finally, the currently available JDKs are not certified to run on symmetric multiprocessing (SMP) machines, so you may have some problems if you attempt to run your servlet server on one. I have not verified this myself, but I have read in the various news groups that the combination of the IBM JDK 1.3 and the most recent release of the glibc library (on Linux) seems to be a winner, albeit one still officially unsupported on an SMP machine.

Again, the installation instructions for the JDK vary, based on the operating system and version you choose. Be sure to carefully read and follow the installation instructions. To ensure that Tomcat can find your Java installation, you’ll need to define an environment variable with the name JAVA_HOME that points to the directory containing your Java installation. (In my case, that would be /usr/local/java.) To ensure that this variable would be available to every profile, I modified the file /etc/profile and added the line JAVA_HOME=/usr/local/java and, in the same file, added JAVA_HOME to the list of exported variables. There were some other changes to the file, which you can inspect. My version of /etc/profile is shown as Figure 2. For tips on how to make switching between Java Virtual Machines (JVM) easier, see my article “Java + Linux = Easy 5250 Emulation,” AS/400 Network Expert, January/February 2000 [Editor’s note: In Window NT, you can set your environment variables in the Environments option from the System Properties panel (evocable from Control Panel) or, optionally, you can modify the tomcat.bat file found underneath Tomcat’s bin directory.]

How Many Servlets Could a Servlet Server Serve if a Servlet Server Could Serve Servlets?

Having recently had the pleasure of configuring WebSphere on my company’s AS/400, I wasn’t really looking forward to doing the same on my laptop. The Tomcat server proved to be a very pleasant surprise. To start with, Tomcat itself is written in Java. Therefore, it’s portable to any platform with a JVM. But most remarkable is how incredibly simple it is to install, at least on the Linux platform. It is literally as simple as extracting the .tar file [or
.zip for Windows NT], adding a couple of lines to a Linux configuration script, and adding one line to the Apache configuration file. But I digress.

Point your browser to Apache’s Jakarta Project Web site (jakarta.apache.org) and you’ll find information on Tomcat and associated projects. Once you’re curiosity has been sated, click on the Tomcat link to find the download links. I’d suggest that you select the Tomcat 3.1 Release Build unless you really like to be on the bleeding edge. Click on the Tomcat 3.1 link and you’ll be taken to a directory listing of /builds/tomcat/release/v3.1/bin/. At first, you may find the long list of files a little confusing. The only files that are required to get things rolling are the files jakarta-tomcat.tar.gz (a 1.8 MB download)
and—following the links, linux/, i386/—the file mod_jserv.so (a 98 KB download). The only difference between the files ending with the suffix .Z and .gz is the type of compression used when building the file. I selected the .gz version of the file. If you’re going to be loading this on a Windows machine, you’ll need to get the files jakarta- tomcat.zip and win32/i386/ ApacheModuleJserv.dll.

Once these two files are downloaded to your computer, you can start the installation. You’ll need to decide where to place Tomcat. I typically place software that I’ve acquired separately from my Linux distribution in the /usr/local directory. In this case, I did a cd /usr/local/applications and then issued the command tar -xzf (download directory)/jakarta-tomcat.tar.gz, which extracted the .tar file into the directory /usr/local/applications/jakarta-tomcat [for Windows NT extract using WinZip]. The documentation refers to the installation directory as simply tomcat, so this little command renames the directory so that the installation matches the docs:

mv jakarta-tomcat tomcat

The documentation is in HTML and can be opened in your browser as the file tomcat_ug .html, which can be found in the directory /usr/local/applications/tomcat/doc/uguide (assuming that you are using the same directory tree as described here).

The last step was to create another environment variable so that Tomcat could find itself. I added to /etc/profiles the line TOMCAT_HOME=/usr/local/applications/tomcat and included TOMCAT_HOME in the list of exported variables, just as was done with JAVA_HOME. Again, refer to Figure 2 for the changes. As you can see, there really isn’t a lot to do in a base installation of Tomcat, although you’re not quite done yet if you want to use Tomcat in conjunction with Apache. You need to make the final modifications and configure Apache to call Tomcat when appropriate.

Earlier, I indicated that you should download the file mod_jserv.so. Apache is a well-designed application that was built to be extensible by using externally created modules. The module mod_jserv.so enables Apache to communicate with Tomcat. You’ll need to move this file to the directory /etc/httpd/libexec/ (or ApacheModuleJServ.dll to Apache’s modules directory on NT), since this is the directory specified by Tomcat in the configuration file tomcat-apache.conf. Finally, include the entries required for Tomcat in the Apache configuration file by adding this line to the end of Apache’s /etc/httpd/conf/httpd.conf file:

include
/usr/local/applications/tomcat/conf/tomcat-apache.conf

You are done with the basic installation. Apache is now ready to work with Tomcat and you’re ready to test the installation.

For these two packages to work together correctly, you’ll need to start Tomcat first, then Apache. Every time Tomcat is started, it rewrites the tomcat-apache.conf configuration file, which is then read by Apache through the Include directive placed in the Apache configuration file earlier. First, ensure that Apache is currently stopped. On a Red Hat system, you can accomplish this by issuing the command /etc/rc.d/init.d/httpd stop. Next, start the Tomcat server by issuing the command /usr/local/applications/tomcat/bin/tomcat.sh start (or the startup.bat command in Windows NT). Tomcat will spit messages to the terminal session where it was started. If you don’t want them, just add > /dev/null to the command and they’ll be routed to the bit bucket. Finally, start Apache with /etc/rc.d/init.d/httpd start and you’re ready to test. Point your browser to localhost:/examples/servlets and, if all went well, you will see the screen shown in Figure
3.

Hey Big Boy—Wanna Share Some OS/400 Data?

Now that you have a fully functional Web server that’s complete with servlets and JSP, you’ll want to turn your attention to the database on your AS/400. It should be understood that you need to have TCP/IP installed and configured on both your PC and your AS/400, so I’ll assume that this is not a problem. As long as either machine can PING the other, you’re good to go. If not, consult the appropriate documentation to correct this deficiency.

All that remains is to download the IBM Java Toolkit for the AS/400. If you’re using Linux, the easiest way is to use FTP. If your AS/400 is configured for FTP and you have it running using the Start TCP/IP Server (STRTCPSVR *FTP) command, issue the command ftp as400_name and sign on with your user ID and password. Then request binary downloads with the bin command and cd /QIBM/ ProdData/HTTP/java/lib/ followed by get jt400.jar. Windows users can access the same file through the Network Neighborhood if their AS/400 has been configured with NetServer. Be sure to also add the full qualification of jt400.jar to your classpath.

Writing Java servlets on this new platform is the same as if you’re doing it on the AS/400. That’s one of the joys of Java. The only change you’ll need to make to any servlets written with your PC as a target is to ensure that you include a user name and password in the call to the getConnection method. Connections made to one AS/400 from a different system (AS/400 or other) are required to provide these two things for authentication: a user ID and a password. The connection statement is written in this manner:

con = DriverManager.getConnection(“jdbc:as400://myas400”,”myuserid”,”mypasswd”)

That’s it. Simply compile your servlet and move the resulting class file into the directory /usr/local/applications/tomcat/ webapps/examples/WEB-INF/classes and it will be available to your browser as http://localhost/examples/ servlets/MyServlet.

In a Nutshell

I have described a simple way to create a Web server using an inexpensive PC and cheap MIPS to supplant those provided by your AS/400. I use this setup to create and test servlets without affecting the production machine. You’ll invariably want to change the Tomcat configuration to allow you to place your classes in different, more appropriate directories. In addition, you may want to make other changes too, such as the number of

Tomcat instances running. Instructions for all of your options are in the Tomcat documentation. It actually took much longer for me to write this article than it did for me to install everything described. Don’t hesitate to give this a try!

References and Related Material

Apache Software Foundation Web site: www.apache.org

Blackdown Organization Java-Linux Web site: www.blackdown.org

IBM Java Developer Kit Porting Web site: www.ibm.com/java/jdk/index.html

“Java + Linux = Easy 5250 Emulation,” Barry Kline, AS/400 Network Expert, January/February 2000.

Linux Documentation Project Web site: www.linuxdoc.org/
HOWTO/HOWTO-INDEX/hardware.html

Microsoft Windows Hardware Compatibility List Web site: www.microsoft.com/hcl/default.asp

Red Hat Linux Hardware Compatibility List Web site: www.redhat.com/support/hardware

Sun Microsystems Java Technology Web site: www.java.sun.com

“Tomcat for the OS/400: An Open Source Web Application Server,” Don Denoncourt, Midrange Computing, December 2000

The Jakarta Project Web site: http://jakarta.apache.org

Figure 1: Here’s what you see after you successfully install the Apache server on Linux.

# /etc/profile

# System wide environment and startup programs
# Functions and aliases go in /etc/bashrc

PATH=”$PATH:/usr/X11R6/bin”
PS1=”[u@h W]$ “

ulimit -c 1000000
if [ `id -gn` = `id -un` -a `id -u` -gt 14 ]; then
umask 002
else
umask 022
fi

USER=`id -un`
LOGNAME=$USER
MAIL=”/var/spool/mail/$USER”

HOSTNAME=`/bin/hostname`
HISTSIZE=1000
HISTFILESIZE=1000

INPUTRC=/etc/inputrc

# NETSCAPE STUFF
MOZILLA_HOME=/usr/local/netscape

# JAVA STUFF
JAVA_HOME=/usr/local/java
SWING_HOME=/usr/local/swing
JAVALIB=/mnt/D/JavaLib

# Standard java classes
CLASSPATH=./:$JAVA_HOME/lib/classes.zip

# AS/400 classes
CLASSPATH=$CLASSPATH:$JAVALIB/jt400.jar:$JAVALIB/jui400.jar

# mySql
CLASSPATH=$CLASSPATH:$JAVALIB/mm.mysql.jdbc-1.2b/mysql_comp.jar

# TableGen stuff
CLASSPATH=$CLASSPATH:$JAVALIB/ewin:$CLASSPATH:$JAVALIB/tablegen-1.8:$JAVALIB/tablegen-1.8/dbgeneric/
PATH=$PATH:$JAVA_HOME/bin

# Tomcat customization
TOMCAT_HOME=/usr/local/applications/tomcat

export PATH PS1 HOSTNAME HISTSIZE HISTFILESIZE USER LOGNAME MAIL INPUTRC JAVA_HOME SWING_HOME CLASSPATH
MOZILLA_HOME TOMCAT_HOME

for i in /etc/profile.d/*.sh ; do
if [ -x $i ]; then

. $i
fi
done

unset i

Figure 2: Here are the changes I made to /etc/profile to make Tomcat run on my Red Hat Linux system.

Figure 3: Success! This is what you’ll see when Tomcat is up and running.