The Internet has become as integral to the world of business today as the typewriter was to business in the 1950s. If your business hasn’t begun to allow its users and customers to access your AS/400 data through a Web browser yet, it’s going to find itself left in the dust very quickly. If your business is in this situation, catching up isn’t as hard as you might think. Most of the tools needed to get your AS/400 data and information to a Web browser already exist. This article takes a look at some of those techniques and how they are used.

Static HTML

One of the easiest ways to serve data to a Web browser is through the use of static HTML forms stored on your AS/400 in the AS/400 Integrated File System (AS/400 IFS). In this context, static means that you present the user with Web pages that are display-only. That is, they do not accept input from the user, although they quite likely allow the user to link to other HTML forms. Using this method, you would use a PC word processor such as Microsoft Word to create HTML documents. If you want to really make your HTML forms sing and dance, you may want to use a product such as Microsoft FrontPage Express, which is designed specifically for creating Web content. Once the forms are created, you move them to a directory you create on your AS/400 by either FTPing them or using Windows Explorer to drag and drop them into the chosen directory after you map a network drive using Client Access/400, AS/400 NetServer, or a similar product.

Your next step is to configure your IBM HTTP server for AS/400 instance setup to allow a browser to access the directory where you stored the forms. For our purposes, you really need to add only one line to the HTTP configuration file. Add a PASS directive that points to the directory on your AS/400 where your new HTML forms are stored. If you have a directory named MYHTML, for example, your PASS directive looks like this:

PASS /MYHTML/*

In your browser, enter the URL http://100.1.1.1:80/MYHTML/ Welcome.htm. In this example, “100.1.1.1” is the TCP/IP address defined for your system, “MYHTML” is the name of the directory defined in the PASS directive, and “Welcome.htm” is the name of an HTML form you stored in the MYHTML directory. As shown in Figure 1, you should

now be able to see your HTML forms from your browser. In this example, I specified the port address of 80. However, any available port or none at all may be specified. If you don’t put a port number on the URL, the default port of 80 will be used.

This is the fastest way I know of for getting your AS/400 to serve Web content to a browser. You can use this technique for generating easily accessible help text or user documentation. At this late date in the millennium, pretty much any high school kid knows enough HTML to convert your user manuals to some pretty jazzy-looking Web pages. Hire one of these kids, who are anxious to get their foot in the door anyway, and let the kid do the grunt work of converting your existing documentation to HTML forms. You’ll end up with a product that, in your users’ eyes at least, is light-years ahead of anything you’ve ever given them before.

Common Gateway Interface (CGI) is one of the most common methods of serving data to Web browsers, such as Netscape Navigator or Microsoft Internet Explorer. CGI is a Web development method that uses a wide variety of programming languages, such as C++, Perl, and Java. The AS/400 supports CGI programming through the use of APIs, RPG IV, the ILE version of COBOL, or pretty much any other AS/400 ILE language. Basically, this works by using an ILE program to develop dynamic HTML forms that interact with the user’s Web browser. The ILE program generates the form, using the appropriate HTML tags, and then calls an API to write that data (which is an HTML string) to the user’s browser. The user responds to the information in the browser and clicks on a button to submit or accept the response. The ILE program then reads the data off of that browser, again calling another API, and processes the request.

This is a pretty standard means of allowing a user to interact with an AS/400 via a browser. A motivated programmer can use CGI to create some very active, interesting, and dynamic Web pages. The bad thing about CGI is that it does not maintain a true persistent connection, which could lead to more programming effort on your part. However, if
you’re interested in pursuing this method of programming for the Web, you’re in luck. Check out the article called “Remembrance of Things Last” by Ted Holt in the September 1999 issue of MC. This article details a method for implementing persistent CGI so you can avoid such things as reopening and repositioning files.

Another way to get started in CGI programming, without having to learn a lot of the ins and outs of it, is to use a product from IBM called Net.Data, which is a macro-processor language that can be thought of as middleware between your AS/400 and the client’s Web browser. Let’s take a look at how it works.

The client browser displays a Net.Data-generated HTML form that prompts the user to enter a product number. The user enters the number and clicks on a Submit button. A request in the form of a URL is passed to the Net.Data server program, which “looks up” the location of the macro you developed in Net.Data to process the request. That macro, which can execute any program on your AS/400, returns the requested data to Net.Data, which then builds another dynamic HTML form based on logic you define and pushes that form out to the browser. The user then sees a Web page that lists the description and price of the product number entered.

Use Net.Data to rapidly Web-enable your AS/400 data. Be warned, however, that Net.Data is notoriously slow. If you want a system that allows the users to have fast response times, Net.Data may not be the way to go. On the other hand, if you are going to be displaying only a small amount of data on the Web, with relatively low user interaction, Net.Data is a great way to quickly get your apps out on the net.

CGI

Net.Data

Java

According to the popular press, Java is the penicillin to the information industry’s influenza of computing diseases. I doubt that this proves to be the case in reality. I can’t see Java solving all the world’s problems. However, Java is a very useful language, and the fact that it is platform-independent makes it ideal for serving Web data. Covering even the basic aspects of Java programming would take more space than is available here, but suffice it to say that learning Java isn’t that hard. Once you start to get into it, you’ll find that Java programming is even easier than programming in a language such as RPG.

Using Java, you can write an applet that displays a Graphical User Interface (GUI), which can be displayed in a Web browser. Java supports literally thousands of methods and classes for customizing the user interface. Add to that the fact that you can extend any of these classes and customize it to meet your needs, and you can see how Java GUI design can quickly reach infinite proportions and provide unlimited flexibility. Take the example of online Internet gaming. One Java applet can be shared by however many users the server can support, simply by starting a new thread to the same applet. This allows multiple online gamers to play against one another as if they were all running the same program. Java truly was designed for the Internet.

Once you develop the Java applet that displays your AS/400 data, displaying it in a browser is as simple as creating an HTML form that contains the HTML keyword Applet. The applet tag contains options that tell the browser where the Java class you want to run is stored. Then, when the user displays that HTML form in the browser, the Java class, or applet, will run. Figure 2 shows the HTML form to display the Java code of a Java class named Compare and what it looks like in a browser. This is a very simple applet that compares three user-inputted numbers and displays the results. The idea behind this example is to show you how easy it is to create a small Java applet and then display it in a browser. The actual Java class and HTML form for this example can be downloaded from www.midrangecomputing. com/mc/. Java can also be written for the server side as server applets, which can then dynamically construct HTML, much like CGI does. The nice thing about Java used on the server is the fact that Java can support multiple threads and performs its own housekeeping or garbage cleanup, something CGI cannot do. Use Java when you want the most flexible, scalable method available for serving data from your AS/400 to a browser.

Paying Dividends

These are some of the easiest methods for serving AS/400 data to a Web browser. Using one of the techniques presented here doesn’t require your shop to spend a lot of money purchasing new products, as you probably already have almost everything you need in- house. Getting your AS/400 data onto the Web will pay enormous dividends for your business as your customer base grows through ease of access to your AS/400 data.

References

• Net.Data Web site: www.software.ibm.com/data/net.data/docs/noframes/ 400/dtwa2m02.htm
• Web Programming Guide V4R3 (GC41-5435-02, CD-ROM QB3AEQ02)

Related Materials

• “Remembrance of Things Last,” Ted Holt, MC, September 1999
• “Serving Up Host-based Java Apps,” Don Denoncourt, MC, August 1999
• “Untangle the Web with RPG and CGI,” Bradley V. Stone, MC, September 1999

Figure 1: Displaying static HTML forms in a browser from your AS/400 IFS is a breeze.

Figure 2: This is all the HTML you need to run a Java applet in a browser.