Stupid Telnet Tricks

Telnet server software can solve some interesting problems

A little more than a year ago, while I was researching Windows NT-UNIX interoperability, I stumbled across an NT product that lets you Telnet into an NT system and establish a character-mode, command-line session. I remember thinking that this product was quite a curiosity--after all, who needs a Telnet server for NT? What on earth would you do with such a thing?

Since that time, NT has worked its way into countless enterprise environments around the globe and has established a solid reputation for solving enterprise-oriented interoperability problems. Of course, solving these problems often means using NT in ways it was never designed for in the first place--such as using an NT Telnet server product to let non-PC devices run character-mode DOS applications and access network-based resources. Strange how yesterday's curiosity can become today's hot technology.

Although the specific Telnet server product I looked at a year ago has since left the market, new products have come into the market to replace it. Today you can get commercial Telnet server products from Softway Systems and Seattle Lab, or get a shareware Telnet server from Ataman. Even Microsoft must think this technology is important because the company released a prototype Telnet server on the workstation and server Windows NT 4.0 Resource Kit CD-ROMs.

Apply to Affected Area
Are you still wondering why you might want an NT-based Telnet server? Let's look at a couple of scenarios from my past that illustrate how you can benefit from this technology.

Scenario 1: Application Access. In my last job, I worked for a company that designed, manufactured, and marketed interoperability gateways. We had no common desktop device in our company--we used UNIX workstations, PCs, AS/400 terminals (5250s), mainframe terminals (3270s), Digital VAX terminals (VT400s), and HP3000 terminals (HP700s). The problem was that everyone needed to access one simple DOS-based program that generated the checksums for our software licenses.

We didn't have our own solution to this problem, so a lot of people burned up productive time trying to find a PC that had the checksum program. If we had installed an NT system, we could have used an NT-based Telnet server to solve this problem. All the commercial host systems we used (i.e., the AS/400, mainframe, Digital VAX, HP3000, and UNIX systems) supported outbound Telnet access; so from each host, we could have initiated Telnet sessions into NT to run the DOS-based checksum application.

How typical is this case? Well, DOS has been around for more than 10 years, and plenty of companies purchased or developed DOS-based apps but didn't convert them to Windows-based apps. For example, I bet you could fill a room with NT Server systems to run all the character-mode dBase and FoxPro applications still in use today. Telnet provides a quick-and-easy way to access DOS-based applications, regardless of the kind of device sitting on the desktop.

Scenario 2: Network Access. When I worked at the gateway company, customers frequently asked us to provide a way for non-PC devices to access information and resources on a PC LAN. For example, a user wants the capability to look at information stored on a file server or print that information on a LAN-based printer from any kind of terminal. One solution is to implement a full-scale interoperability product to integrate the file systems and printers of the two (or more) systems. Unfortunately, this type of solution is usually quite costly.

Here again, Telnet access to NT can solve a number of simple terminal-to-LAN access problems. If you store your information in text files or a character-mode application maintains it, you can access the information via network drives. Remember, with NT and the NET USE command, you can mount and unmount network drives from the command line easily. The same techniques apply to printing--you can mount and unmount network printers with NET USE and direct output to the network printers using either the PRINT or COPY command. Alternatively, you can use the LPR command to send files to a TCP/IP-based printer.

Is this solution elegant? No. Is it even pretty? Not really. But does it cost $75,000 to implement (like a typical full-blown interoperability solution)? Hardly. Just keep this solution in perspective--an NT Telnet server provides a simple solution for some very specific access needs.

Seeing Is Believing
I wanted to see how well an NT Telnet server product could handle Telnet traffic, so I decided to test it using an AS/400 I happen to have in my office (doesn't everyone have one?). This test represents a real challenge for a Telnet server, because the native AS/400 terminal (the 5250) is a full-screen, block-mode terminal, much like its 3270 brethren. Block-mode interaction, of course, is very different from the character-mode interaction that occurs in most Telnet sessions.

On the NT side, I used Ataman Software's shareware product, Ataman TCP Remote Logon Services. The software is simple to install--you unpack the files to the directory of your choice and then start the Telnet server service with the following command-line directive:

telnetd install start

This command installs and starts the Telnet server software as an NT service.

Once the Telnet server software was running, I simply started a Telnet session from the AS/400 using its native (as of OS/400 V3R1) Telnet facility. In response, I received a prompt for a username and password. After I entered valid user information (from my local Security Accounts Manager--SAM--files, in this case), I received a command prompt, as Screen 1 shows. From the command prompt, I was able to run simple commands, character-mode applications, and a handful of full-screen applications (e.g., the DOS Edit program). All things considered, I was impressed that this process worked as well as it did.

Great Expectations?
What can you expect from a Telnet interface to an NT command-line session? Well, most DOS and character-mode NT commands are pretty straightforward because they were written as simple text-mode utilities. However, if you want to run more sophisticated programs, such as the DOS full-screen Edit, terminal access gets a little tricky because you have to press keys that may not exist on your terminal's keyboard (e.g., the Alt and Ctrl keys).

Fortunately, the Telnet server software I looked at includes keyboard-mapping facilities that let you generate PC keystrokes from a non-PC keyboard. In the case of character-mode terminals, such as Digital VT terminals, this process is straightforward: You can assign Ctrl-key combinations and function keys to PC keyboard values.

For IBM 5250 and 3270 terminals, this keyboard mapping process is not as straightforward because the host-based Telnet software first translates the native IBM keyboard into a VT100 or VT220 keyboard. Consequently, you must handle two levels of mapping: the map for IBM-to-VT keyboard handling and the map for VT-to-PC keyboard handling. Oh sure, this process is not exactly brain surgery, but it does add a level of complexity to the environment.

The good news is that you usually need to set up keyboard maps only once. After you perfect your maps, you may be surprised at what you can do with this simple terminal interface (I know I was).

Not for Everyone
Is an NT Telnet server the newest paradigm for thin-client computing? I don't think so. Should you rush out and deploy an NT-based Telnet server as a core component in your mission-critical business solution? I wouldn't. An NT Telnet server is clearly not a high-end, high-powered interoperability solution. Now don't get me wrong--I don't mean that an NT Telnet server has no value at all. In fact, NT Telnet can be a low-cost, highly effective solution for some small, hard-to-reach problems. Just think of Telnet as a worthy entry in your ever-growing bag of neat NT tricks, but not the latest and greatest TCP/IP solution for world peace and harmony.