TELECOMPUTING TODAY
Arlan R. Levitan
Uploading And Downloading
The fine art of saving and sending information over phone lines via modem is often a source of bewilderment to folks just starting out in telecomputing. The most frequently asked questions that appear in my electronic mailbox are:
"How do you download files from bulletin board systems or commercial information services?"
"How can I send copies of programs that I have written to other computers with a modem?"
"How can I compose the electronic mail that I write to my friends ahead of time to avoid having to pay for typing my letters while online?"
All of these messages typically end with the phrase, "I've tried every way I can think of to make this work. Help!"
Saving information received via modem for later use (downloading) and sending information to others (uploading) is not that difficult. Successful file transfers don't require deep technical knowledge—just a basic understanding of some fairly simple concepts.
What It Takes
The ultimate success of your attempts at uploading and downloading depends on a number of things:
- A terminal program designed for your computer that has the proper capabilities. Terminal software that does not specifically include features for uploading and downloading stands about as much chance for success as David Stockman floating a personal loan from the Joint Chiefs of Staff. You wouldn't book a seat on a plane that doesn't have wings, would you? Don't expect terminal programs that weren't designed with file transfers in mind to do the job. We'll review the most useful features to look for later.
- Proper operation of the terminal software. This is up to you. The fact that your terminal software allows file transfers is no guarantee of success, just as owning a car is no guarantee that you'll qualify for a driver's license. In both cases, knowing how to properly operate the technology in hand is the key. There's an old data processing saw that goes, "The difference between a novice and an expert is having read the manual." Old as its teeth may be, that saw still cuts pretty true. Before getting started, think out the sequence of instructions that must be issued to your terminal program and to the remote system.
- Software running on the remote computer that is compatible with your computer and terminal software.
It's not enough that your terminal program allows file transfers; the software at the opposite end of the line may not have every feature supported by yours. This is where some people get hung up (pun unintended) through no fault of their own. If either program deviates slightly from the agreed-upon protocols, one of them may figuratively throw up its hands and scream "I quit!" We'll look at why this happens more frequently than it theoretically should (usually with different type computers and/or terminal programs on either end of the link).
Avoiding Errors
If every link in the telecomputing chain doesn't work perfectly, errors will result, but the tolerance for error varies. Text files are usually less critical than program files. If, for example, the word COMPUTE! were changed to COMPOTE! by line noise or some other error, a person reading the text would probably notice the mistake and be able to infer how the word is supposed to read.
This isn't true with program files. The file must be an exact duplicate of the original or it won't run—or perhaps worse, it might run and yield inaccurate results. You could inspect the file, but a machine language program looks like a bunch of binary garbage to the average person. It's practically impossible to spot an error by context alone. For this reason a method of error checking is essential to transmitting binary files intact.
Capturing Information
The easiest type of downloading to implement in a terminal program is simple text capture. After you switch on this feature, all the information that appears on your system's screen is also transferred to another storage medium. The most flexible terminal programs allow incoming data to be saved in a disk file, a memory buffer (a reserved block of memory), or directly to a printer.
Saving to disk is fairly quick and allows you to read, print, or even modify the information later. If data is saved in a memory buffer, the terminal program fences off a large portion of Random Access Memory (RAM) as a temporary storage area. Usually you can view this buffer and turn it on and off as you desire.
Since your computer has a limited amount of RAM, most terminal programs warn you when the buffer is nearly full so you can instruct the remote system to pause while you transfer the buffer to disk. A memory buffer with this feature is nice to have if your computer's disk drive is not particularly quick. Otherwise, you'll be constantly waiting for your disk drive to keep up with the information you're receiving. (In fact, some computers cannot transfer incoming information directly to disk without losing pieces of data.)
Dumping the information to a printer leaves you with a handy record, but it can burn up a lot of paper and also makes it kind of tough to pour all of those printed characters back into your computer.
XON/XOFF Pacing
You might be wondering how, as mentioned above, you can instruct a remote computer to pause while you transfer a memory buffer to disk. Most information services and bulletin board systems (BBSs) use a convention called flow control to act as a traffic cop during transmission. The most common flow control scheme uses the character produced by hitting CTRL-S on your keyboard as the signal to temporarily stop sending information. (If your computer lacks a CONTROL key, check your terminal program manual for a substitute. All terminal programs have some way of sending standard control codes.) CTRL-S is the transmission-off or XOFF signal. CTRL-Q is the transmission-on or XON signal.
These key combinations let you stop and restart the information that zips across your screen. Similarly, the software in the remote system and your computer can automatically use XON/XOFF to insure that incoming data is halted if either computer is busy handling some other chore for a few moments.
XON/XOFF is generally an option you can set in most commercial terminal programs and should be turned on ordinarily. Since the XON/XOFF characters are not usually visible on your screen, most people are completely unaware of their use.
Error-Checking Methods
Soon after people began using microcomputers for telecommunications, it became apparent that a reliable system was needed for transferring binary program files.
Ward Christensen, a coauthor of the first microcomputer BBS, developed a public domain terminal program for CP/M systems called MODEM7. When MODEM7 users logged onto Christensen's BBS and asked to transfer a binary file, they instructed the BBS to run a utility program called XMODEM.
The basic XMODEM ground rules laid down by Christensen back in 1976 are still used today by almost every BBS, regardless of which computer it's running on. The XMODEM protocol, as it's called, also is available for transferring files on the CompuServe and Delphi information services.
In next month's column, we'll examine XMODEM in detail and show step by step how the uploading process works. We'll also cover some tricks for saving money when sending E-Mail messages. Until then, BCNU.
Arlan R. Levitan
The Source: TCT987
CompuServe: 70675, 463
Delphi: ARLANL