Telecommuting for the VS Remote network connections using SLIP
From "Migration",  Access to Wang, October 1995
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Last month we covered remote workstation connections to a VS host using the traditional terminal emulation/host model. Many of us have been using this approach to remote communications, so this model should be familiar. If you use VS applications for all of your application needs - electronic mail, word processing, etc. - than this terminal emulation approach will work well, providing fast, reliable, and inexpensive connections to your enterprise systems.

Increasingly, software on the VS provides only part of the application solution: there are other tools and other hosts that we would like to use. Dial-up communications can be provided for each of these purposes separately, but this usually means that you must perform only one task at a time. For example, if you were working on the VS using a terminal program and dial-up line, you would have to end your session and log off before dialing in to check your electronic mail. Using a single application at a time was acceptable a decade ago, but today most of us expect simultaneous access to all of our applications.

Since most of the applications we are interested in using are run from a network, the following discussion is based on such use. Applications that make use of data or applications on a remote system can be thought of as client/server applications - certainly a term echoed in much of the trade press today.

Using network applications remotely

Here are several ways to gain access to network applications from a remote location:

1. Use a bridge or router: Lay an expensive digital line from your organization to the remote location, and purchase the required communications equipment. Requires a large investment for each connection ($7,500 or more plus several hundred dollars a month in line charges) but provides fast, reliable connectivity.

2. Connect to a PC that is on the network: Use commercial products (PCAnywhere, Carbon Copy, etc.) to remotely control a PC that is locally attached to the network. Requires two PCs to be up and functioning for each connection, and may be slow and unreliable.

3. Use special connection hardware: Purchase a commercial network connection product that provides network connections across dial-up lines. Expensive but often faster than some other options. Costs $2,000-$5,000 per connection. (This is a hot field today, so check trade magazines and vendors for the latest products.)

4. Extend the network through serial protocols: Use SLIP (Serial Line Internet Protocol) or PPP (Point-to-Point Protocol) and an appropriately configured PC to dial into the enterprise TCP/IP network and share network applications. Requires a suitable communications server (Unix, Windows NT, etc.), normal communications equipment (modems, conventional phone lines), and network client software on the PC. Can be difficult to set up.

As you can see, the last option (SLIP or PPP) provides an excellent cost/benefit ratio and is often the best solution, allowing you to use the same applications as you would on local systems. (SLIP and PPP are similar in concept, so I will use the term SLIP to refer to either.) Much of the additional software needed for a SLIP connection is available for little or no cost, and performance is reasonable. Drawbacks to SLIP center on getting it correctly set up on both client and server.

The illustration below (see Figure 1) shows how SLIP connections work. The modem on the remote workstation makes a connection with a modem on the communications host, then both systems step aside to allow network packets (chunks of data) to pass across the line. With appropriate security and access control, applications and data on any system accessible to the enterprise network can be reached, no matter what platform type or physical location.

On the remote workstation, the communications client software translates network packets, feeding them to the application software. Types of application software can include any software that can receive data from the communications client software, such as network terminal emulation (Telnet clients), LAN email or word processing applications, or FTP (File Transfer Protocol) tools.

A guided tour

Much of the discussion to this point has been abstract and not helpful to the network application novice. Perhaps the best way to see how SLIP access works is to provide a typical scenario:

• You are working from home today to get some additional work done on a large presentation without the distractions of the office. You would like to remain in contact with your department through email, though, so you can handle important tasks. The materials for your project are spread across three storage areas: a diskette in your briefcase and two servers at the office. Local communication tools include a personal computer (PC-compatible), a 14,400-baud modem, SLIP communications software, a telephone line, and the same application suite you use at work.

• At the start of the day, you launch the communications client software and wait until it has established a connection with the office communications server. After the modems are in communication and a network connection established, you start the email client and check for new messages. When you are finished you leave the email software running so you can be notified of new mail.

• Messages read, you are ready to begin work on your project. The first task is to gather all of the project files together, so you start a terminal session (Telnet) with the Wang VS and log on. After locating the file you need and queuing it for transfer, you set the VS terminal session aside for later, too.

• The next file to retrieve is located on the department server. Starting your FTP client software, you log on the Windows NT system and follow the graphical file map to locate your file. You transfer the file to your local system by dragging its name to the icon representing your system, closing the FTP session when the transfer finishes. Meanwhile, the VS file transfer has completed; you now have all of the files you need for your project.

• Settling down to work, you get in a few productive hours on your presentation, working on both the slide presentation and accompanying documents. Your concentration is interrupted briefly by the arrival of an urgent mail message: there is a background job running on the VS that requires attention and the operator would like you to look into it. Resuming the VS Telnet connection you left suspended, you resolve the problem, reply to the mail message, and return to your project.

• Later in the day you receive another message asking about a business policy that you are unfamiliar with. Business policy and procedure documents are stored in HTML (Hypertext Markup Language) format on one of your servers, providing excellent access for local and remote users. You start up Cello - a World Wide Web (WWW) client application - and follow links within the policy documents, locating the answer to the question within a few minutes.

• Your project finished, you restart the FTP client and transfer all of the project files to a new directory on the department server for safekeeping. While the files are transferring, you check for new mail and discover a notice announcing an improved version of one of the applications you use regularly on your local PC. Launching a second FTP session, you are soon transferring these files from the server to your local system.

• One last check to the VS terminal session and you are ready to quit for the day. You close all client applications before breaking the communications link.

If you have never used SLIP before, the preceding scenario might sound improbable, but I use most elements daily and appreciate getting simultaneous access to multiple applications. Naturally, the speed of the modem connection limits the effective concurrent use of more than one application, so some flexibility is necessary when performing large tasks, such as transferring large files. In general, SLIP connections are nearly as reliable and fast as dial-in terminal emulation sessions.

Getting started

As noted above, getting everything working correctly the first time is the most difficult aspect of SLIP connections. Client communications software requires careful attention to network parameters and some effort to avoid conflicts with other network software - including Windows for Workgroups. Setting up SLIP on the host is tricky and specific to each manufacturer's operating system; I recommend consulting experts in your architecture. Communications equipment should be as fast as cost and the technical capabilities of your system allow: 14,400 baud should be considered the lowest practical speed. Access to the VS through such connections requires a TCP/IP gateway, currently sold by Wang and Software Business Applications.

This discussion was intentionally brief, but it should give you some idea of the benefits and requirements for remote network access through SLIP. Contact me here at the magazine if you are interested in more details about client applications or host communications setup.

Figure 1: Model of Dial-up Network Communications