Many companies with smaller twinax, Ethernet, or Token-Ring networks may not want or need to expose their AS/400s on the Internet. In this article, the second in a series, IT managers can explore some basic dial-in solutions that work with materials you may already have lying around your shop: a network, an AS/400, and some modems. Although these techniques may seem a bit out of date, they still get the job done.

In my previous article in this series (see “Remote Access: The Stuff of Computer Lore,” MC, November 1998), I wrote of a time gone by to add some drama to the piece. In this article, some people may think I’m still discussing a time gone by because I’m strictly covering dial-in, AS/400-based remote-access solutions. While lacking the glamour of their Internet-based counterparts (which I’ll cover in my next article), dial-in solutions work extremely well in small, AS/400-based, twinax, Ethernet, and Token-Ring environments that have limited resources and even more limited Internet capability. In fact, one of the solutions I discuss can even allow your AS/400 to serve as an Internet Service Provider (ISP) for your company intranet.

It’s important to remember that there are still companies that use only 5250 twinax controllers for user access. While this solution may seem anachronistic, the administration and configuration costs associated with it are minimal. In some cases, twinax is the most cost-effective solution because you don’t have to worry about 32-bit versus 16-bit drivers, compatible RAM, interrupt-request (IRQ) conflicts, and card socket services. And—to tell you the truth—having a 5250 green-screen twinax display station connected to an AS/400 is still one of the easiest solutions.

There are also many situations in which an AS/400 is used only for back-office duties (data hosting, security, general ledger, batch check writing, etc.), and lightly networked PCs are required for everything else. These organizations might have a network of twinax-attached devices, or they may employ a Token-Ring or Ethernet network.

Although these situations may appear to be timeworn, they get the job done. In this article, I describe dial-in remote-access solutions that are designed specifically for

companies that use an AS/400 as a server platform without any additional network file servers (such as Novell NetWare, Microsoft Windows NT, etc.). These solutions can be used to dial in to your AS/400 in a twinax, Ethernet, or Token-Ring environment. The one common feature that all of these solutions have is that, while they are concentrating the connectivity (hardware and software) on your network, they take a minimum amount of configuration and hardware on the remote user’s system. In the best-case scenario, they simply require an off-the-shelf asynchronous modem, the user’s operating system, and a plain old telephone line.

Now, I’ll examine what you can do to provide access to your AS/400 network over ordinary phone lines.

Start with Your Network

The first and most important question in providing your users with remote access is, “What type of network do you have?” The three most common answers to this question are Ethernet, Token-Ring, and twinax.

When dealing with networking, several devices (such as routers, bridges, and gateways) are available that tie different networks together. A Remote Access Service (RAS) performs functions that are similar to those devices. A RAS takes information from the Public Switched Telephone Network and converts it to the protocol of your existing network. Because of this, any RAS products that you evaluate need to fit into your existing network infrastructure. Otherwise, the devices will not work or you will need to make concessions to accommodate the new networking type.

However, when dealing with older technology, be aware that there are more RAS products for Token-Ring and Ethernet environments than there are for twinax. The reason for this disparity is that twinax is associated with IBM and its proprietary SNA protocol. Even though techniques for running TCP/IP over twinax cabling exist in certain applications (such as with IBM’s Network Stations), twinax devices still mostly use SNA. In contrast, Token-Ring and Ethernet provide more open standardized solutions.

What About Client-side Requirements?

In determining the expense of implementing remote access, the question to ask is, “What requirements does each remote-access solution place on my remote devices?” Answering this question helps to determine how much remote access will cost you. If you have DOS-based remote clients and the solution requires you to have Windows 95, then you have to assume that your remote users need to purchase Windows 95 licenses. In the worst-case scenario, you may have to replace remote systems because they lack enough CPU power, RAM, or hard-drive space.

Quite a bit of support is available for different PC-based systems. IBM, for example, has DOS, OS/2, Windows 3.1x, Windows 95, and Windows NT support. However, support does not necessarily reach to both ends of the system, and it should. In other words, your remote-access solution must support both your application software and the remote PC operating system.

A number of different interdependencies exist here. The modems at both ends of the connection must support each other. If you’re dealing with standard Hayes-compatible modems, mutual support is typically not a problem. Less-common modem protocols (such as SDLC modems) may present a problem if you do not do your research up front. Software that establishes a connection between the remote user and your corporate network must also be in place. This software must support the modem on the remote user’s system. Finally, the software that establishes the connection must support the application software and AS/400 connectivity method that is used. If any one layer (interdependency) does not support another layer, you will fail to establish a connection between the corporate network and the remote user.

So, where does this leave you? There are several different software and hardware requirements that will be imposed upon the remote user, all of which are dependent upon

your network and how you remotely access it. In the end, you will need to provide a solution that provides minimum disruption for your remote users and their systems.

How Secure Should Remote Access Be?

You should always have some form of security that authorizes a remote-access session based upon user ID and password. I have actually heard people ask, “Why are a user ID and password required for dialing up to a network? Unless you broadcast the dialup phone number, you should be safe.” This is dangerous thinking because hackers dial numbers sequentially as they attempt to find a data line. If user IDs and passwords are not required, a critical barrier is removed and a hacker can “walk” right in to your network.

Another important security issue is how well your RAS fits into your existing security infrastructure. Some remote-access solutions require you to create user IDs and passwords on the device that receives calls from remote users. Depending upon your organization, you may have to train an already-overworked person to maintain the remote- access device and enter passwords for each authorized user. Only two people can be blamed for password exposure: the user and the person who maintains user IDs and passwords.

Other remote-access solutions integrate directly with your AS/400’s security so that, if the user ID and password exist on the AS/400, the remote user is allowed to access the network. An AS/400-centric solution requires less up-front configuration and setup. You do not have to create user IDs and passwords. This capability removes a step when a new user enters your system and when you are initially setting up remote access.

I recommend finding a solution that integrates into your existing security infrastructure; such integration will save you time, both initially and in the long run. However, there may be other requirements that are more important, and security integration may need to be sacrificed. If this is the case, then, at a minimum, make certain that you require a user ID and password to sign on.

What’s the Market Like?

Now that I’ve reviewed some key configuration areas, I’ll examine what the industry offers in the way of AS/400-based remote-access solutions. This is by no means an authoritative list of what is available. Rather than doing an intensive marketplace review, my intent is to provide a basic understanding of the available dial-in PC-to-AS/400 connectivity techniques.

Network PC Dial-up Server

This PC-to-PC-based solution involves using a PC server in your corporate network that contains a special modem card capable of accommodating both asynchronous and twinax connections. This card has one or more RS-232 connections and a twinax connection. You connect a number of standard asynchronous Hayes-compatible modems to the RS-232 ports while connecting the twinax port to your existing twinax network or your AS/400. The asynchronous modems wait for remote clients to dial in and then establish a connection to your twinax network. In addition to the corporate PC-server hardware, a specific application (or an entire operating system) is dedicated to creating users, establishing AS/400 connections, and managing those connections.

Remote systems that dial in to this system use a standard modem. There are no particular hardware requirements, just that the modem supports the Hayes command set and any necessary connectivity software. Depending upon the vendor, most popular operating systems such as DOS, Windows 3.1x, and Windows 95 are supported. In most cases, the RAS hardware vendor that you choose will have software that enables the remote user to create a connection and access the AS/400, although I would recommend checking with the RAS vendor to see if the software you use to access the AS/400 is supported by the RAS hardware you use.

One of the keys to implementing remote access is to avoid requiring expensive hardware on every system that needs access to your AS/400. Hence, the PC-to-PC-based solution is a good one because no special hardware is required for the remote user’s

system. Asynchronous Hayes-compatible modems are usually priced around $100 per modem and can be purchased from any personal computer store. Several different vendors provide dial-up-to-twinax solutions, including Perle (http://www.perle.com) and IBM (http://www.as400.ibm.com).

Twinax Dial-up Server

The twinax dial-up server is similar to the PC dial-up server previously mentioned. However, it is an all-in-one hardware and software solution.

On the corporate network side, you install a hardware device that contains both RS- 232 connections and a twinax connection. Like the PC solution, the RS-232 ports allow you to connect external modems to the dial-up server. The twinax connection allows access to your corporate twinax network or to the AS/400.

With this solution, you eliminate the requirement for a server PC at your location. This works to your benefit because you don’t need to worry about finding hardware that is compatible with the dial-up card. However, this solution is more expensive than using a PC dial-up server.

As with the dial-up card, this is a fairly inexpensive and easy-to-deploy solution. The range of software and hardware that is supported on the dial-up client is quite broad, and with the new modem standards that are emerging, this solution is very fast. If you are performing strictly 5250 green-screen emulation, then there will be little performance difference than if you were directly connected to the AS/400.

One aspect to consider is how the AS/400 “sees” the remote clients. When dealing with dial-in-to-twinax situations, the AS/400 simply acknowledges additional twinax stations that are treated like any other twinax device with the same polling intervals. This is an important capacity-planning consideration. For AS/400s that are highly optimized toward a specific number of workstations, this remote-access solution may be a requirement rather than an option. With other types of remote-access solutions, either TCP/IP or IPX/SPX is used to communicate with the AS/400. The AS/400 was originally optimized to communicate using SNA, and you still experience the best performance with SNA-based communications. Using another protocol may increase CPU utilization on your AS/400 above what you would experience with SNA communications.

Vendors that provide twinax dial-up cards often have twinax dial-up servers as well. So, there is support for this type of solution aside from that provided by niche- solution vendors.

Direct Dial-in to Your AS/400 Using TCP/IP

Aside from external dial-up solutions, the AS/400 can now act as a TCP/IP dial-up server, allowing access to OS/400 and other network systems. With recent operating system releases (V4R1 and above), the AS/400 can now act completely on its own and provide a viable remote-access solution.

Before V4R1, OS/400 lacked several different components for effective dial-in access. The first was Dynamic Host Configuration Protocol (DHCP), which allows the AS/400 to assign TCP/IP addresses to client systems that do not have TCP/IP addresses. Without this feature, an IP address would need to be configured on each system that was dialing in. If you had multiple modems, you would need to ensure that each remote system you configured had a unique IP address.

Another key component that is now available in OS/400 is Domain Name System (DNS), which allows you to resolve host names to Internet Protocol (IP) addresses using the TCP/IP networking protocol. Without this feature, you would need to deploy a list of host names and IP addresses to each remote system. Anytime a new server was added or renamed, a new host file would need to be dispersed. With DNS, a call is made to the server for the IP address of a host name, and the management of the IP addresses and host names is performed centrally.

However, the technology that makes direct dial-in solutions possible is Point-to- Point Protocol (PPP). PPP is a standard that defines how remote devices encapsulate and

transmit data packets. PPP provides the transport between two modems so that TCP/IP can be used on dial-up lines. PPP is now available on the AS/400, and it opens up an exciting number of new possibilities for direct AS/400 access using an asynchronous modem.

With PPP, DHCP, and DNS, the AS/400 can now efficiently function as a remote- access platform. To enable AS/400 remote access, Windows 95 users can dial in to an asynchronous modem that is directly attached to the AS/400 (through an ASCII Workstation Controller). Windows 95 includes a dial-up networking component that allows remote users to dial up to remote-access servers (such as your AS/400). To do this, users configure a new dial-up networking connection to use when they call in to your AS/400. They also reconfigure their TCP/IP dial-up connection (inside the network configuration option of their Windows 95 control panel) to specify the address of the AS/400’s DNS server so that they can resolve TCP/IP addresses when they are connected to your AS/400 network.

When users dial in from Windows 95, the AS/400 assigns an IP address and some other configuration information via DHCP. A successful connection is created, and the user starts up the application software. The application software knows that the AS/400’s host name is http://www.as400e.com but does not know what its IP address is. The user’s computer then queries the AS/400’s DNS server to ask what the IP address of system http://www.as400e.com is. This IP address is returned, and the application software now runs properly from the AS/400. With these relatively simple steps, an AS/400 has become a remote-access server.

The final concept to mention is that, if your AS/400 is connected to an Ethernet or Token-Ring network, your remote user can access intranet hosts other than the AS/400 through TCP/IP. The AS/400 can act as a router and place requests from the remote user to a network that the AS/400 is directly connected to. Furthermore, if your AS/400 has a route to the Internet, your remote users can access the Internet as well as your AS/400 and any other systems in your corporate network.

This scenario can be a launching point or a test bed for larger remote-access implementations. It utilizes common TCP/IP network technologies, such as PPP, DHCP, and DNS. With these technologies, your AS/400 can act as an ISP that allows users to access your companywide intranet and the Internet through an AS/400-based dial-in connection. If you run an AS/400 shop with a spare ASCII communications controller and OS/400 V4Rx, I would recommend this approach.

Generic Dial-up Servers

Generic dial-up servers deal with devices that provide modems and dial-up servers bundled into one computer. They provide generic dial-up access to Ethernet and Token- Ring networks rather than specific remote access to an AS/400. These devices provide support for all common networking protocols including TCP/IP, IPX/SPX, NetBEUI, and even Logical Link Control (LLC). They are versatile and provide an open connection to your network as opposed to a conduit to a specific hardware platform. An example of this type of device is the IBM 8235 dial-up server. The 8235 allows you to install up to eight modems in the unit. It also includes support for all of the networking protocols listed above.

However, these devices lose some appeal in the area of security. Typically, generic dial-up servers will not integrate with your AS/400 security. Some of the more-intelligent devices can import user IDs and passwords from Windows NT or Novell but do not provide tight integration with the AS/400.

So, What Do We Have?

In all of the examples outlined in this article, I’ve presented remote users with standard modems. They use these modems to dial up to a remote-access hardware platform. The solutions can be connected to a twinax network, an AS/400, or an Ethernet or a Token-Ring network. The prerequisite that I kept throughout this discussion was that the requirements placed on the remote user’s system must be kept at a minimum.

You can almost assume these days that, when you buy a PC, a modem will be included with it. If not, then $100 gets you a modem that supports the latest in bandwidth technology (56K, V.90, etc.). Providing a remote-access solution that supports commonly used modems benefits you in three ways: From a monetary perspective, you do not have to buy hardware for each user who wants to dial up the AS/400. From a configuration perspective, you do not have to install a new piece of hardware on the PC of each user who wants to dial up. Finally, from an administrative perspective, you do not need to own or administer numerous devices.

From the network side, you only have to provide modem access to your network or to your AS/400. This access can be provided through individual modems or modem banks attached to a PC dial-in server, a twinax dial-up server, your AS/400, or a generic dial-up server. The network hardware waits for a remote system to dial in. When a connection is attempted, it queries the remote system for a valid user ID and password. Once authenticated, the hardware device converts any requests from the remote user to the protocol of the network it is attached to.

On the surface, many of these dial-up scenarios appear to be dated, employing as they do technology that is not much used anymore. However, for some situations, these are excellent alternatives and get the job done. For something to work well and be reliable, it does not have to shine.

Coming Up Next in Remote Access

In the next and final installment of this series, I will look at the remote-access technology that many people believe really does shine: Internet-based remote access. I’ll bounce around a lot of different concepts, including (among others) HTML screen refacing, Citrix MetaFrame and Microsoft Terminal Server, and TCP/IP-based Internet access. Stay tuned as we finish our three-part tour through the wild and wonderful world of AS/400-network remote access.