Everyone wants AS/400 access over the Internet, but no one seems to agree on the best way to accomplish it. This article takes a high-level overview of what your options are for Internet-based remote access to your AS/400 and what benefits and problems each approach offers.

Your boss just left your office, grumbling that remote users need to be able to access your AS/400 through the Internet—now. There is no time to rewrite applications. Remote access has to be available immediately, or something is going to hit the fan.

In this article, the final installment of my three-part series on remote access solutions, I intend to present some solutions to the Internet-now scenario I just described. I’ll discuss some emerging technologies that may not be solid today but will become increasingly important in the future. I’ll start by bringing to light the thin client paradigm, and I’ll explain how it is evolving to the Internet. Then, I’ll contrast thin client with some other possible solutions that can help satisfy your boss’s requirement to get AS/400- Internet access for your remote users—sooner rather than later. I end the article with some security considerations and my own recommendations for which solutions I believe will stand the test of time and serve your organization the best.

Thin Client Implementation

The thin client approach deals with communications between a desktop and a server. The server performs graphics rendering, calculations, networking calls, database calls, and printing. The client accepts only the updated network data streams and displays screens and processes printouts. Because the client performs minimal work, we call it a thin client. And, whenever you have a thin client, you need a fat server (one that has lots of processing power, RAM, hard drive space, etc.).

This type of solution is now being ported to the Web. A current demo from Citrix (www.citrix.com) renders surprising performance. Keystrokes and input are processed quickly with little latency in the update.

Up to this point, Citrix has been the main player that is serving thin clients to the Web. However, Microsoft’s current thin client implementation is a port of Citrix’s, so look to Microsoft to support this in the very near future.

So now, I’ll quickly describe how this architecture works. Suppose one of your remote users is connected to the Internet. He brings up special software that is installed on his PC. This software ties into your fat server and receives screen updates. In your situation, the fat server could be serving out Client Access/400 and other applications that you use internally. And guess what: The screens your user is seeing are identical to what he’d see if he were directly connected. This translates into less training and fewer calls for your help desk employees, who are using the same software.

What I really like about this solution is that there is only a single piece of software installed on the remote user’s PC, no matter what is used internally. Imagine you are a network administrator for a company that has at least 10 individually packaged applications on each desktop. Using a thin client implementation, you can install one piece of software that lets your remote users access all 10 applications and whatever else is on your fat server. You need not install anything on the remote system except the remote software.

Contrast this with the hassle of installing all 10 pieces of software and getting them to work together, and you begin to appreciate the obvious advantage here. A single piece of software reduces the number of points of disturbance on your remote client. A point of disturbance is a piece of software that could conflict with another piece of software. Once any potential conflicts are worked out on the fat server, you eliminate conflicts on the thin client.

The major downside to this solution is that it is still vaporware. Expect approximately one year for the proof of concept to occur. At that point, I believe you will see this scenario being deployed in large quantities.

One additional problem is that Citrix is one of the only vendors supporting this form of thin client. IBM, for example, performs its thin client implementation on a thin client device. When you boot this device, you must download the operating system that sits in main memory. If your base operating system is 3 MB, you will typically have to wait 10 to 15 minutes on a 28.8 kilobits per second (Kbps) modem. I can tell you that if my users have to wait 10 to 15 minutes for their systems to start up, they start screaming.

Client Access Direct Connect

With Client Access/400 supporting the TCP/IP protocol, nothing is stopping you from attaching your AS/400 to the Internet and having your users connect to the AS/400 from the Internet. You can easily do it, but you must take special precautions to make the connection secure.

By using the Internet, you can provide your users with the same interface, whether they are locally or remotely connected. Client Access/400 is installed on the remote user’s system. Once connected to the Internet—via modem, cable modem, ISDN, asymmetric digital subscriber line (ADSL), etc.—the remote user simply starts Client Access and the connection is completed.

TCP/IP was initially designed and deployed on slower links (less than 2,400 bps). The protocol can handle slow links between a remote user and the server (in our case, an AS/400). When the Internet is slowing down from high use, your response time will decrease, but you will still be able to operate.

So, if you’re able to use the Internet to deliver the same interface to your users no matter where they are located, is there a downside? Your primary exposure is security. Several different components are included in Client Access. Each of these can potentially operate on a different TCP/IP port. At your firewall—and you should always have a

firewall—you will have to open up all of these ports. This situation provides hackers with additional entrances into your network.

Also, you cannot impose encryption. Client Access/400 performs some encoding of user IDs and passwords, but it currently does not perform standards-based encryption such as Secured Sockets Layer (SSL). About a year ago, IBM field engineers began to push for implementing SSL in the operating system. This implementation would allow all applications, including Client Access, to take advantage of encryption. With the new IBM AS/400 Client Access Express for Windows (Express Client), SSL encryption is beginning to be implemented, providing a huge security feature.

The other problem with this solution is that it does not encompass other applications. It is limited to Client Access only. Services such as file and printer sharing from a Windows NT Server do not function over this arrangement without installing additional software. Only applications that are strictly TCP/IP based and perform name resolution using Domain Name System (DNS) can work over the Internet. And with additional applications, additional ports have to be opened on your firewall.

Screen Refacing

Screen refacing technology has been building steam for a while with companies such as SEAGULL Software (www.seagullsw.com) pioneering the way. With screen refacing, the 5250 data stream is hidden from the user and a nice graphical interface is presented instead. The reasoning behind this approach is that, because a 5250 green-screen is considered clunky and obtrusive, putting a graphical interface over it allows the screen to become more appealing to a Windows-oriented user.

If you have Client Access/400 installed, you can see an example of screen refacing in action. There is a licensing deal between SEAGULL and IBM to include SEAGULL’s Graphical Access screen refacing product as part of IBM’s Client Access/400 for Windows 95/NT product. The nice thing about using Graphical Access in the Windows 95/NT client is that it is included in the base support of Client Access/400, and you do not need a Client Access license to use it. For the Windows 95/NT client, this means that Graphical Access is essentially a free GUI terminal emulator that can be installed on any machine without needing Client Access licensing.

[Editor’s Note: Please be aware that IBM’s licensing deal with SEAGULL is not being extended to IBM’s new AS/400 Client Access Express for Windows (Express Client) product. Graphical Access will not be offered as part of the new package. The result is that you can still use Graphical Access if you are running Client Access/400 for Windows 95/NT V3R2M0 and below. However, if you move to the new Express Client product, Graphical Access will no longer be an option, and you will need to license a commercial terminal emulation product, either IBM’s PC5250 or another commercial emulator, instead.]

As the Internet became a more predominant technology, screen refacing began migrating to HTML as the presentation layer. An HTML engine residing on the AS/400 receives HTML requests from a browser. The engine converts those requests to 5250 data stream requests and sends them to OS/400. The AS/400 processes the requests and sends the resulting 5250 data stream back to the HTML engine. The engine converts the data stream back to HTML and sends it to the Web browser that made the request.

There are several products now available that provide HTML-based screen refacing. I/Net (www.inetmi.com) sells the Webulator/400 product that provides an HTML interface into the AS/400. IBM also adopted this technology for the AS/400 when it released its own Web server, which is currently bundled with its other TCP/IP-based applications and is called Workstation Gateway (WSG).

With HTML-based screen refacing, you can quickly deploy green-screen applications to the Internet. However, this is a “quick-and-dirty” solution because, although your applications may be on the Web, they will not look and function nicely.

HTML does not provide context-sensitive help, and you cannot access function keys from your keyboard. Typically, you have to click on a button that has the “F1” caption on it.

Depending upon the vendor, a single screen will not fit completely in a browser window. The user is required to scroll down to see the entire screen. This is more of a cosmetic issue than anything else: Since all of the data is visible, it simply requires some manual intervention to see the entire screen being presented.

Another issue is that HTML-based screen refacing creates a big CPU hit on your AS/400, and it’s not hard to see why. Whenever a user enters a command, menu option, or function key, the AS/400 receives this event and converts the request to a native AS/400 5250 screen. The AS/400 processes the screen and returns the result. The result is then converted from EBCDIC 5250 to ASCII-based HTML. Because of all the conversion involved, the AS/400 performs a lot of additional work.

If you are evaluating HTML-based screen refacing, ensure that the vendor supports encryption. Without encryption, user ID and passwords flow over the Internet unencrypted and are viewable as plain text. You should avoid this major exposure at all costs.

Java-based 5250 Emulators

At the same time that the limitations of HTML-based screen refacing were becoming apparent, a new technology was emerging: Java-based 5250 emulators. Various vendors began refacing 5250 green-screens with Java. By screen refacing with Java, vendors can provide context-sensitive help, the use of function keys, and functionality that mimics 5250 terminal emulation programs.

Farabi Technology Corporation was one of the first companies to offer this technology (www.farabi.com). Its HostFront product downloads a Java applet to your browser. The applet lets you sign on to an AS/400 and use the AS/400 as if you were directly attached to it through a 5250 Terminal Emulation package.

If you want to deploy 5250 green-screen applications to Internet users, this technology has potential. It provides enough functionality to compete with other 5250 emulation packages, and there is no software to be installed on the remote user’s desktop. It is all downloaded on demand. And the added bonus is that most vendors that provide this software, including Farabi, include SSL encryption, ensuring that your data is viewed only by the user it is intended for.

VPN to the Desktop

Virtual Private Networking (VPN) is a technology that allows two locations to create a virtual network connecting each other through the Internet using TCP/IP. The virtual network replaces a dedicated connection or leased line arrangement, lowering the operating costs of your WAN arrangement.

VPN is typically set up between satellite locations and the head office. The satellite location has a small number of users and cannot justify the expense of having a leased line. So, for communications with the head office, a VPN is implemented.

With the success of this technology, there is a movement to widen the support to connect individual desktop users as well as corporate networks. Organizations want to create VPNs between their corporate network and their remote users, no matter where they are physically located. Some obvious benefits of this setup are as follows:

• All transmissions are encrypted, which keeps your data and passwords private.
• The solution works for your Client Access/400 applications, as well as any other applications you have installed. It does not limit what applications access the other end of the VPN.

• All applications run over a single conduit, which means that all applications are funneled into a single TCP/IP path and then expanded once they reach the other end of the VPN. This translates into less configuration of your firewall.

Of course, there are some downsides to a VPN implementation. All applications must be installed on the remote user’s desktop. This requires disk space and configuration

time. Typically, you must also have the users bring their systems to you to configure. But users generally do not like their home computers venturing away from home.

With this type of technology and the number of vendors that are starting to deploy it, the word incompatibility comes to mind. Standards are starting to emerge, but the desire for this technology came before the standards. With VPN, this means that every vendor does the same thing differently. Right now, there is very little cross-vendor support. So if you are going to use this technology, ensure that you are employing VPN technology from a single vendor.

Also, because this is an emerging technology, support is still limited. However, VPN will become a vital remote access technology in the future.

What I Left Out

Most vendors that deal in Internet security say that you should never place your production systems on the Internet. However, in most of the above scenarios, there are additional layers that separate your production AS/400 and the Internet.

Look at the thin client implementation. In order for your thin client users to access the AS/400, they must first have authority to the fat server. If they do not, then they are denied access to the AS/400. Therefore, you are not directly putting your AS/400 on the Internet.

Now, look at IBM’s WorkStation Gateway/400. To allow access to this application, you must place your AS/400 on the Web. I recommend that, for security purposes, you port your applications over to a new AS/400. With the AS/400 being as scalable as it is, this could simply mean backing up from your production AS/400 and restoring to your Internet-bound AS/400. From there, you would have to set up replication for any updated information between the two servers.

Whatever means you choose, keep in mind that there should be some barrier between the Internet and your production system. This provides a barrier between those deadly hackers and your AS/400.

What the Future Holds

In the first article in this series (see “Remote Access: The Stuff of Computer Lore,” MC, November 1998), I mentioned remote access as it was implemented in days gone by. Since then, I have shown the evolution of remote access and how to use modems to connect directly to an AS/400—through a dial-up server, through a fat server, and through the Internet.

VPN to the desktop and thin client over the Internet have the best possibility of withstanding the test of time. However, like COBOL and even the AS/400, modem-based communications will not be phased out any time soon. They will simply mature and become cheaper and faster.

More and more vendors are moving to support the Internet and accessing the AS/400 through it. The future has Internet written all over it, and, over time, we will be forced to support remote access more and more. Luckily, there are more tools available every year that make that job easier.