I think we’ve all gotten the message IBM is sending; the AS/400 is a business computer extraordinaire. But imagine how great it would be if the AS/400 could serve up arcade-style video games. You know, the kind that has exploding missiles, sound effects, and bright flashes of color. If the AS/400 could really be a game machine, then its future as a client/server platform would be proven! Right? After all, any architecture that can handle the demands of the modern video arcade game has the power to handle the interactive demands of the most stringent client/server applications.

“Dream on,” you say. “The AS/400 is a true-blue business machine, and it’ll be a cold day south of the border before it runs Doom.” Don’t be so hasty to dismiss the AS/400. Java is transforming the AS/400 into a server with incredible power. With Java applications and Java applets, the limitations of the AS/400 seem to have been shattered. To prove this to myself, I decided to see how easy it was to add a Java-based video game to our AS/400’s HTTP server. If that process proved easy—and if the response time was robust—then why should I waste time with NT’s Internet Information Server or any other server architecture?

Figuring It Out

Of course, the first hurdle was to figure out exactly what I needed to do. IBM ships an HTTP server with OS/400 as part of its TCP/IP package. Within Version 4 of OS/400, the DB2 WWW HTTP server and Net.Data come along free. However, since I don’t have Version 4 yet, I scrambled through the documentation. Unfortunately, it really didn’t give me much useable information. The only thing it said was that I had to configure the TCP/IP and the HTTP server software. The first thing I did was type in CFGTCP to get to the TCP/IP Configuration menu. I selected option 20 (Configure TCP/IP applications). Next, I selected option 14 (Configure HTTP). That displayed the Configure TCP/IP HTTP menu.

I selected option 1 (Change HTTP attributes) to see if I could find anything to help me figure out what to do. This is shown in Figure 1. The only thing this display told me was that the HTTP server was set to autostart when TCP/IP was launched on the AS/400. Next, I tried option 2 (Work with HTTP configuration). This displayed the actual configuration of the HTTP server as shown in Figure 2, but this information didn’t resemble anything like an AS/400 configuration; it was a series of statements in some sort of text file that looked vaguely like program syntax.

I was about to give up when I thought, “What the heck? Why not start the HTTP server, launch a browser, and see where I go?” I keyed in the command STRTCPSVR *HTTP and let the AS/400 launch the HTTP server. Then I loaded up my Netscape browser and blithely keyed in the IP address of my AS/400. Presto, I got a default Web page. “This means the AS/400 is storing some HTML code somewhere,” I thought. “I wonder where.”

Life on IFS

I figured I would probably find the code would be is in the Integrated File System (IFS). The IFS can hold ASCII and EBCDIC files, and as I already knew that HTML would need to be in ASCII format, I guessed this was the place to look. I keyed in GO FILESYS and was sent to the IFS File System menu. I selected option 2 (Object commands), then option 1 (Work with object links). Lo and behold, there was a link for a directory called html. I chose option 5 (Next level) to take a peek at what was inside, and there I found a list of HTML files of the type of STMF (for stream files) and other names with the type of DIR (for directory). The list is shown in Figure 3. I wasn’t sure how to display them at first, but another flash of insight saved me. “Why not go into the IFS with Client Access/400 using Network Neighborhood?” I thought.

I clicked on Network Neighborhood, selected the AS/400 icon that represents my system, and then clicked on through to get to the folder called html. From within this folder, I could click on the file named default.htm, and my Netscape browser showed me that it was indeed the Web page I’d seen before.

Here’s what I’d found out so far: First of all, configuring and starting the HTTP server seems to be a no-brainer. HTTP is there, waiting to be used once TCP/IP has been set up. Second, the HTML Web pages are on the IFS, stored in a folder called html. You can get to them either through the AS/400 FILESYS menu commands or, if you have Client Access/400 Windows 95/NT client on board, slip in through the Windows 95 Network Neighborhood interface. “It seems pretty well integrated,” I said to myself. “I think I’ll try putting a Java applet in the html directory to see how well it runs.”

Intermission: A Brief Message about Java

Let’s stop for a second and look at what Java is, what it offers, and why it’s becoming so important. Java is an object-oriented programming language that was designed by Sun Microsystems. Its claim to fame is that it allows applications to run on multiple operating system architectures. It accomplishes this nifty trick by defining a set of base functions—or classes—that have been standardized into something called the Virtual Machine. Each OS vendor writes the underlying operating system calls to be executed by the Virtual Machine for the associated piece of machine hardware. Java classes are divided into two kinds of programs: applets that run on the client and applications that run on the server.

Within the Internet community, Java applets were first introduced by Netscape to run within the Netscape browser. Microsoft soon followed, making this feature available for the Internet Explorer. When a Java-enabled browser accesses a Java applet on a Web server, the applet classes are downloaded into the browser’s Virtual Machine and executed. This is currently the most popular use of Java on the Internet, and many Web sites have been enhanced with small visual applications that interact with browsers to provide visually

exciting buttons and sounds. Other Java applets include games, 3D presentations, and Internet phone appliances.

On the other hand, Java applications—classes that run on the server—interact with the server’s base operating system to provide access to databases, I/O resources, and all the other facilities that are available. IBM is currently building a Java application development toolkit (JDK) specifically for the AS/400. It is currently available in beta on the Web at http://www.as400.IBM.com. This JDK makes the entire capacity of the AS/400 available for creating full-fledged client/server Java applications. The implication for AS/400 programmers is clear: The JDK is going to be a high-powered client/ server tool. When it’s finally released, you and I will be able to build complete client/server applications in Java that will make the need for IBM’s Client Access/400 package seem redundant. Instead of loading up the PC 5250 terminal emulator, we’ll be able to use a Java applet from within any Java-enabled browser to access our data. Ultimately, a whole new realm of Java- enabled emulators and applications will flood the market, allowing us to build exciting user applications without worrying so much about the ins and outs of OS/400. The JDK is scheduled for release in the first quarter of 1998.

Back to the Game Plan

So now I knew where I should put my own Web page: inside the html folder of the IFS. I also knew that I could theoretically put a Java applet in that folder and access it from my Web browser. I didn’t have time to write and test my own Java application, so I surfed the Web for some freeware examples. I finally found a good one by Sergio Fanchiotti called UFO Attack; it’s at http://www.rur.com/
javacode/Ufo_Attack. It’s a masterful Java representation of a typical arcade-style game that lets you shoot down UFOs. Sergio provides the complete Java source code for his class at the Web site, so if you want to investigate how it works you should check it out. The applet came as a set of files (including the source) that were archived as a ZIP file.

After I downloaded the ZIP file, I created a new folder on the IFS with the html folder. I accomplished this using the Network Neighborhood File/New/Folder selection. I renamed the folder Stockwell. Because I had connected to the IFS with CA/400’s Windows 95/NT client, this process was no different than creating any new folder with the Windows Explorer. I unarchived UFOATTACK.ZIP directly into this new Stockwell folder on the IFS. So now what? Theoretically, when I keyed in the URL of http://[mycomputer]/html/Stockwell, I should have received a browser listing of all the files in the Stockwell folder.

Mayday! Mayday!

Unfortunately, when I typed in the URL, the HTTP server returned a message saying that my access to the Stockwell folder was denied. Somehow, my rights to this folder were different when I was a Web user than when I was a Client Access/400 user. But where could I change the security attributes?

After scrounging around for a while, I determined that I needed to go into the IFS from my terminal emulator and add a new user authority to the newly created Stockwell folder. I would also need to do the same thing to each of the files within that folder. I keyed Work with Link (WRKLNK) html/Stockwell and took option 9 (Work with authority). See Figure 4. I added the User Authority called QTMHHTTP with an Object Authority level of *RX. This *RX authority would give any HTTP user the ability to access and use the directory, but will not let him or her remove or alter it.

Now I had a choice to make. Since all the files contained within the Stockwell folder had obtained their authority levels when they were unzipped, they too would be inaccessible from a browser unless I changed them individually. Changing each file would have taken a long time, so I chose to remove them and recreate them. This move allowed the new versions of the files to take on the security attributes of the parent folder, which

included the authority level of QTMHHTTP. If I had known all this up front, I could have saved myself some grief, but you live and learn.

I went back to my Netscape browser, keyed in the URL of my new Stockwell AS/400 Web page, and alien ships began descending towards earth, complete with music and other sound effects (see Figure 5). Fortunately, my rockets could knock the aliens off pronto, and after only a few moments my score card was starting to look very respectable. The UFO_ATTACK Java applet had loaded very quickly and it was performing flawlessly. And the overall AS/400 performance? It was not only respectable, it was fantastic! From this, I concluded that the Web serving capacity of the AS/400 is an industry secret (Sssh...don’t let anybody at Microsoft know.) Here I am, with my very own AS/400 video arcade, knocking these critters silly! George Lucas, eat your heart out.

You can try this at home, friends. If your boss is curious, you can try it at work, too. (Yeah, right!) The point of the demonstration is simple: If the AS/400 can perform this well as a Java slurping Web server, pouring out arcade games, imagine how robust it will be as a Java application server pushing out client/server business applications written in Java. Maybe this is a good reason to learn Java coding. Maybe the AS/400 is not just a business machine. Maybe those long winter nights up in Minnesota have gotten some IBM programmers focused. The future is bright; we’re taking back the darkness. We’re definitely in the Internet client/server game now. Go forth and conquer! (And may the Force be with you.)

Figure 1: Searching for a Way into http

Showtime

Figure 2: Investigating the HTTP Configuration Figure 3: Working with Object Links in the IFS

Figure 4: Adding an Authority Level for http Figure 5: May the Force Be with You!