Telecommunications power. (includes related articles)
by Tony Roberts, Eddie Huffman

Wake up, telecommunicators! You're working too hard. The rest of the world has moved up to automated telecommunications while you're still waiting for prompts and typing account numbers and passwords.

If you telecommunicate, it's time you looked into ways to automate the process, and there are several reasons why:

* You can save time.

* You can save money.

* You can have fun programming your PC.

If telecommunications is part of your business, you know that saving time is essential. The sluggish economy, business downsizing, and increasing competition force every worker to find ways to be more productive. If you can find ways to increase what you can do in a day, you'll protect your job and build skills for your career.

Whether you're a business or home telecommunicator, saving money is always an issue. Automated telecommunications allows you to accomplish more in less online time, keeping both online charges and telephone line charges down.

Ten years ago, computer programming--mostly in BASIC--was a part of every computer user's day. You needed a litte programming here and there just to keep your system going. Programming became a challenging hobby enjoyed by thousands of computer owners who were able to use their newly learned skills to create useful software for their families and businesses.

The evolution of computing, however, has left would-be recretional programmers twiddling their thumbs. Systems have become so complex and software has become so advanced that it's almost impossible for the average person to write application software that's really useful or that can compete with today's off-the-shelf programs.

Unless you're going to throw your life into it, it's difficult to justify the expense of a software development package and all the tools and research materials that go with it.

If you own a telecommunications program, however, you probably have the tools at hand to embark on some small programming projects that have a purpose. You can use your program's script language to create custom software that's useful for you, and in so doing, you can save time and money and complete a challenge.

If you're not up to programming, don't desert me. It's possible to automate telecommunications sessions in other ways, including the use of keyboard macros and dedicated front-end software programs. In fact, serious telecommunicators will probably adopt a combination of these methods. See "No Programming Required" for more information on these nonprogramming alternatives.

An Elementary Guide to

Script Writing

Every telecommunications program has its own script language, but most telecommunicators take one look at the script language manual and stop cold.

Even some programmers are put off by 200 pages of cryptic commands. Don't lose your cool. Getting started is easier than it looks.

Although these script languages have the raw power to produce huge and complex programs, most homehacker telecommunications chores can be accomplished with a handful of commands.

If you can figure out how to do the following four things, you can write telecommunications scripts.

* Dial a telephone number.

* Watch for specific information coming in over the modem.

* Send and receive characters.

* Send and receive files.

This article will show you how to accomplish these tasks using the script languages provided with Procomm Plus and Telix, two popular telecommunications programs. Even if you have a different package, fillow along, because chances are that the commands your program offers are similar.

Both Procomm Plus and Telix include sample script files on their distribution disks. If you have Procomm Plus, look for files with ASP extensions; if you have Telix, look for files with SLT extensions. The rationale for these extensions crystallizes when you realize that Procomm Plus scripts are created with the Aspect language, and Telix scripts are created with a language called SALT.

These sample files are excellent references for command usage. In fact, some of these programs can be put right to work. Both programs offer a script that logs on to CompuServe once you fill in your account number and password. That script can then be modified to work with other services you call.

Programming Prologue

* Both Aspect and SALT are C-like languages. If you don't know C, don't worry, the scripts you write as a beginner will consist of a start and a finish with a few program lines in between.

*Both script languages allow you to use variables and require that they be defined before they are used. However, manay simple scripts, including the ones used here as examples, can be written without varibles.

* Finally, most of the commands available in script languages have far more options than the beginning programer can use. Many commands also provide a return value. This is a code that your program can use to verify that the previous command was successful. Return values are crucial in complex programs that run unattended, but simple programs that are built to save to tedious repetitive keystrokes usually can do without them.

Dialing

Both Procomm and Telix can associate scripts with dialing directory entries. That is, you select an entry from the dialing directory; the program dials and establishes a connection. Once the handshake occurs, the s cript kicks in.

However, sometimes it's convenient to include dialing commands in your script. This might allow you to execute your scripts from DOS or from another program such as dBASE.

Basic Script Commands

Command Telix Procomm

Dial a number DIAL DIAL or MDIAL

Wait for text WAITFOR WAITFOR

Send characters CPUTS TRANSMIT

Manipulate buffer CAPTURE LOG

Download file RECEIVE GETFILE

Upload file SEND SENDFILE

NOTE: In the syntax examples for the Procomm Plus telecommunications commands, some parameters are separated by the vertical bar symbol, represented by the character I. This symbol should be interpreted as "or," and only one parmeter should be used at a time.

In the Telix examples, command parameters are placed in parentheses and are separated by commas. The examples also indicate what kind of parameter is required--str indicates a character string parameter, and int indicates an integer. All Telix statements must concluded with a semicolon.

Dial a Number

Procomm:

DIAL "[ldcode]entry[ldcode]..." strvar[message]

or

MDIAL "[Idcode]number[idcode]"

strvar[message]

Telix:

DIAL (str, int,

int);

Procomm Plus uses separate commands to handle numbers selected from the dialing directory and manually entered numbers. DIAL plucks a number from the dialing directory and initiates the call. If you want to call the service that's listed fifth in your dialing directory, DIAL 5 will do the trick. If special long distance codes need to be added to the number, they can be appended before or after the dialing directory number as appropriate.

Manually dialed numbers are simply entered with the MDIAL command as in MDIAL 555-1212.

Although it may seem easier to select manual dialing for many simple scripts, there's an advantage to using the dialing directory. The dialing directory entries contain the settings for each service you call. By using the dialing directory, you ensure that your telecommunications parameters will be correct. Under manual dialing, however, the program establishes a connection using whatever settings and parameters are currently in effect.

In Telix, one command does all the work. In its simplest form, you enter the dialing directory entry number for the service you want to call, such as DIAL("5");. Other parameters you can add indicate the number of times Telix should attempt to establish a connection and a code to deactivate a script that's associated with the dialing directory entry.

The command DIAL("4", 10, 1); would dial entry number 4, try ten times to make a connection, and not run the script file associated with the dialing directory entry. If the second parameter, maxtries, is 0, DIAL will attempt to make a connection until it is either successful or halted by the user. If the no-link parameter is either not included or set to 0, the script associated with the dialing directory entry will

SAMPLE SCRIPTS

PROGRAM 1: Procomm Plus Aspect Script ;* Procomm Plus script to log on to local BBS ;* and capture all mail into default log file. ;* PROC MAIN ;* Call entry number 1 in dialing directory and log on at prompts DIAL "1" WAITFOR "First Name:" 15 TRANSMIT "Tony" TRANSMIT "[caret]M" WAITFOR "Last Name:" 15 TRANSMIT "Roberts" TRANSMIT "[caret]M" WAITFOR "(Y/N)?" 15 TRANSMIT "Y" TRANSMIT "[caret]M" WAITFOR "Password:" 15 TRANSMIT "password" TRANSMIT "[caret]M" ;* open log file to capture mail LOG OPEN ;* wait for prompt from menu and issue series of commands to read mail WAITFOR "Choice?" 15 TRANSMIT "R" WAITFOR "?" 15 TRANSMIT "F WAITFOR "first" TRANSMIT "[caret]M" WAITFOR "?" 15 TRANSMIT "C" ;* wait for return to main menu, close log file, and log off BBS WAITFOR "Choice?" FOREVER LOG CLOSE TRANSMIT "G" ENDPROC PROGRAM 2: Telix SALT Script // Telix script to log on to BBS at typesetting service. // This script logs me on to the BBS, then goes through // the steps necessary to upload a file called ROBERTS.ZIP. MAIN() { // dial a number manually rather than use dialing directory DIAL ("m274-8131"); WAITFOR ("First Name;", 15); CPUTS ("Tony"); CPUTS ("[caret]M"); WAITFOR ("Last Name:", 15); CPUTS ("Roberts"); CPUTS ("[caret]M"); WAITFOR ("Y/N?", 15); CPUTS ("Y"); CPUTS ("[caret]M"); WAITFOR ("Password;", 15); CPUTS ("password"); CPUTS ("[caret]M"); WAITFOR ("Choice?", 15); // select menu option to upload file CPUTS ("U"); WAITFOR ("Your choice?", 15); // specify ZMODEM protocol CPUTS ("Z"); WAITFOR ("Filename?", 15); CPUTS ("ROBERTS.ZIP[caret]M"); WAITFOR ("Description;", 15); CPUTS ("File for Typesetting from T. Roberts[caret]M"); WAITFOR ("CTRL-X aborts", 15); send ('Z', "ROBERTS.ZIP'); WAITFOR ("Choice?", 15); // chooise Good-bye from menu CPUTS ("G"); CPUTS ("[caret]M'); }

be activated once the connection is established.

If you don't want to use the dialing directory in Telix, precede the phone number with the letter m to indicate manual dialing: DIAL("m555-1234");

Wait for Text

Procomm:

WAITFOR string [integerFOREVER]

Telix:

WAITFOR(str,int);

The WAITFOR command is central to any telecommunications script. Its function is to keep watch for a specific string of characters that the program needs in order to take its next steps. For example, WAITFOR "Password:" 60 in Procomm plus or WAITFOR("Password:",60); in Telix causes the program to monitor the communications port for 60 seconds, looking for the password prompt. As soon as the string "Password:" comes in or as soon as 60 seconds go by, the program will move on to the next command.

Setting the timeout parameter to 0 in Telix or to FOREVER in Procomm Plus prohibits the script from advancing unless the proper string is received.

Send Characters

Procomm:

TRANSMIT string

Telix:

CPUTS(str);

You'll use these commands to send data, such as your account number, password, and menu selections to the communications port. These commands will usually follow a WAITFOR command.

Assuming your password is "secret*word", you can transmit it in Procomm using the command TRANSMIT "secret*word". In Telix, the command would be CPUTS("secret*word");.

Note that neither language automatically adds a carriage return, so you'll have to do it yourself, either by appending the carriage return code ([caret]M) to the password string or by sending a second command as in TRANSMIT "[caret]M" or CPUTS("[caret]M").

This carriage return code is entered by typing the carat (Shift-6 on most keyboards) and then an uppercase M. This combination is interpreted by the program as Control-M, which is equivalent to ASCII 13, the carriage return character.

This same process can be used to send other control codes such as [caret]G, the bell character, or [caret]J, the linefeed character.

Manipulate Buffer

Procomm:

LOG {OPEN [filespec]

CLOSESUSPENDRESUME}

Telix:

CAPTURE(str;

In many instances, you'll want to capture some information while you're online. The LOG and CAPTURE commands can be used to grab an image of the telecommunications session, or parts of it, and save it to disk as an ASCII file that can be examined later.

Both Procomm Plus and Telix allow you to specify default filenames for this process in their setup utilities. Unless you override those filenames in your script, the captured data will be appended to those files.

In Procomm Plus, use commands such as LOG OPEN, LOG CLOSE, LOG SUSPEND, and LOG RESUME to control the current log file. The command LOG OPEN "data.txt" would opena new log file, DATA.TXT.

The Telix syntax for this function is similar: CAPTURE("data.txt") opens the file DATA.TXT and saves the current telecommunications activity in it. Further buffer manipulation is accomplished with the following commands:

CAPTURE("*CLOSE*"); CAPTURE("*PAUSE*"); CAPTURE("*UNPAUSE*");

If you see a null string ("") in your capture command, as in CAPTURE("");, Telix opens a dialog box allowing you either to select a file to open or to close or pause a currently open file.

NO PROGRAMMING REQUIRED

Key Macros

By assigning frequently used commands--log-on sequences, E-mail retrieval commands, passwords, and so on--to macro keys, you can have one or two keystrokes do the work of many. Not only will you eliminate mistyped commands, you'll streamline your telecommunications sessions and save time and money.

Terminal, the Windows 3.0 telecommunications program, for example, allows you to store frequently used strings on function keys or buttons that you can click with a mouse.

These definitions are retained with each setup you save, so if you call two or three online services or bulletin boards, you can partially automate your telecommunications processes by building a consistent set of macros.

For example, in each setup, place your log-on string (account number, password) on key 1 or button 1 and place the log-off command on key 10 or button 10. If you use other commands, place them similarly in each setup.

Once that's done, you won't have to struggle to recall the syntax for each service; if you're logging on, use key 1, and that's all there is to that.

Front-End Software

Dedicated front-end software programs are designed to work with a specific telecommunications service, such as GEnie, CompuServe, or Prodigy. These programs are structured to minimize online time by allowing you to read data and select information for downloading while offline and to navigate more quickly while online.

If you plan to be a regular user of these services, it pays to investigate these front ends since they're optimized to work with each service. With GEnie's Aladdin, for example, you do most of your work offline--reading messages, composing mail, selecting files to download. Once everything is prepared, press a key, and Aladdin logs on, delivers your mail, downloads selected files, performs any other tasks you've queued up, and then logs off as quickly as possible.

CompuServe's CompuServe Information Manager is a shell that allows you to move about the massive system faster and more efficiently. By using CIM, you can retrieve mail and move to your favorite areas with a single menu selection. Discussion topics and files to download can be marked and retrieved for offline perusal in batches rather than one at a time.

Download and Upload Files

Procomm:

GETFILE protocol [filespec]

Telix:

RECEIVE(int,str);

Procomm:

SENDFILE protocol filespec

Telix:

SEND(int,str);

Activating a telecommunications program's file transfer utility is fairly simple. You enter the send or receive commands followed by parameters specifying a transfer protocol and a filename. Procomm Plus uses full words to specify protocols, as in GETFILE ZMODEM "myfile.txt", while Telix expects the protocol parameter to be a one-letter code as in SEND('Z', "myfile.txt").

These commands are only the final step in an automated file transfer. First, you must make sure you've navigated the host system's menus properly to get you to the right spot and that you've supplied the host with a valid filename for is purposes. Then, only after the host is ready to begin the transfer, your script issues the GETFILE or SENDFILE command.

Uploading and downloading from script files is usually best suited for specific cases in which the same filename can be used repeatedly.

For example, at COMPUTE, orders for disk products are entered into a dBASE database application as they are received. Periodically, a program is run that organizes all pending orders, copies the order information to a separate file, shells to DOS, and activates a telecommunications script that transfers the order files to another location where the disks are packed and mailed.

Depending on the number of orders to process, this series of steps can take an hour or two, so the automation pays dividends by allowing the operator to go off and complete other tasks or even go out for lunch.

In my desktop publishing business, I use a version of the sample Telix script to upload files to a typesetter for high-resolution output. The hard-coded filenames work because I always group my files and a READ.ME file with instructions for the typesetter into a zipped archive with the name ROBERTS.ZIP. I can start the script file and go off to a meeting with a client knowing that the script will keep dialing until the typesetter's constantly busy modem is able to answer and my file is transmitted.

Strategies for Successful

Script Design

One of the easiest scripts to design, and one of the most useful, is a simple script that dials a service, logs you on, and then turns control over to you. This type of script saves you the trouble of remembering and repeatedly retyping account codes and passwords.

Once you have your log-on script built, you can enhance it to gather your mail, fetch stock quotes, or take you directly to a favorite round table where a lively discussion is going on.

To help you create these scripts, turn on your system's CAPTURE or LOG file as you go about your normal telecommunications business. After you log off, print out the file, and you'll have a record of all the prompts you encountered and all the commands you issued in your online travels. Then program those steps into your script and let your program, rather than your fingers, do the walking.

Rest assured, though, that it's not as simple as all that. As you know, different situations pop up when you're online. For example, when you're reading your mail, what prompts do you encounter if you have no mail, have one letter, or have several letters? To build a successful script, you have to anticipate all the possible situations and create a branch in your script for each.

The sample scripts included with this article are simple linear scripts. They start at the top and go step-by-step to the bottom. If problems are encountered along the way, these scripts have no way of recovering. They'll either just sit and wait, not knowing what to do, or rush ahead supplying the wrong commands at the wrong prompts. Nevertheless, these scripts can serve to automate the most repetitive of your telecommunications chores.

After you come to understand the simple commands outlined in this article, however, you can begin to tap the dozens of other commands and functions provided in the script languages. For example, you'll want to begin to test result codes after various operations, such as uploading or downloading a file. By testing the result code, your program will know if the transfer succeeded, and based on that information, the script can either go on to the next step or branch to a routine designed to correct a problem.

For those not familiar with programming, Aspect and SALT scripts are built by combining a series of procedures. In the examples provided here only one procedure, main, is used.

Procomm Plus requires you to declare the procedure with the command PROC MAIN and end it with the command ENDPROC. Telix declares the procedure with the command MAIN and then encloses the commands in that procedure in curly braces ({}). Telix also requires that each program statement end with a semicolon. Subprocedures can be developed that are called from the main command.

Although not discussed in this article, both languages allow the use of variables, and both require that the variables be declared, or initialized, prior to use. Study the sample scripts provided with your telecommunications software to see how variables can be used as counters, to store account numbers and passwords, to hold filenames, and much more.

Before a script can be used, the source code must be compiled. Compiling turns program code that you can read into more compact instructions that the computer understands. If you make changes in your script, you'll have to recompile it before the changes take effect.

Procomm Plus will attempt to compile and run an uncompiled script on the fly, but if it's unable to compile the script successfully, Procomm Plus doesn't provide much information about the problem.

It's usually better to compile your scripts from the DOS prompt using the command ASCOMP scriptname from Procomm Plus, or CS scriptname from Telix. If errors are encountered, the compiler will give you some information about the error and tell you on what line of the script the problem occurred. Then you can go about making the correction and recompiling the script.

Compiled scripts have the same root filename as the original script, but the extension is different. In Procomm Plus, compiled scripts bear the extension ASX, and in Telix, compiled scripts are identified by the SLC extension. Once your script is working properly, you can remove the original source code from the system because it's the compiled version that does all the work. However, be certain to keep a copy of the original on hand in case you need to make modifications. Compiled scripts cannot be reedited.

Procomm Plus Datastorm Technologies P.O. Box, 1471 Columbia, MO 65205 (314) 443-3282 $119

Telix Exis P.O. Box 130 West Hill, ON Canada M1E 4R4 (416) 289-4641 $40

TELECOMMUNICATIONS ON THE GO

Macros and scripts aren't the only path to quick and easy telecommunications. Sometimes a portable modem is what you need. But you can't plug a pay phone cord into a modem jack. I discovered that painful fact one afternoon when I pounded a city's sidewalks for an hour in search of a telephone cord that could be used with my laptop's modem. I never found a direct-line phone connection.

If you have to telecommunicate when you're on the road, you'll truly appreciate the acoustic interface supplied with Com 1's Le Voyager MV 214 modem. Although the model I tested can use a direct-line phone connection (if you can find a compatible jack), the modem works best using a simple acoustic coupler that straps directly to the telephone handset. And unlike earlier generations of acoustic couplers that worked well only on telephones with rounded ear- and mouthpieces, Le Voyager MV 214's coupler swivels and slides to adapt to handsets that are flat, round, or almost any other shape.

The modem itself is a small rectangular box about the size of a deck of cards. Powered by either a nine-volt battery or an optional transformer, it connects to your computer's serial port with a 25-pin cable (purchased separately). There is no power switch; Le Voyager comes on when you access it through your communications software. Compact and powerful (transmitting at 2400 bps normally and 4800 bps or higher using the MNP5 protocols, if you're communicating with a similarly equipped modem), Le Voyager offers business travelers, laptop users, and other mobile telecommunicators an efficient way to send and receive information.

The user handbook is concise and helpful despite its lack of an index and a troubleshooting section. Although it has its positive points, I did discover an anomaly in the handbook. It includes instructions for autodialing while using the acoustic coupler, but it's impossible to autodial with the acoustic coupler.

It's unfortunate that you have to dial manually while using the coupler, particularly if you are using a telephone that dials from the handset; the coupler gets in the way of the keypad.

At first, I had trouble using Le Voyager. My initial connections were plagued by scrolling screens of garbage, but Com 1's helpful telephone support crew came to the rescue. I was able to eliminate the problem by using the JCL command, which lowers the modem's sensitivity to phone line noise.

I tested Le Voyager by transmitting the same file several times at different noise levels from the desktop PC in my home office. The modem had no trouble transmitting clean copy through such routine noises as a stereo and a window-unit air conditioner, but my files quickly became cluttered with garbage when I transmitted while my wife and I shouted at each other and banged on the filing cabinets. The logical next step was to take Le Voyager out into the field. The first try would be from an outdoor phone at an auto racetrack, followed by an attempt from the lobby of an arena where a rock concert was taking place, with the final test from an outdoor phone at Cape Canaveral during a space shuttle launch. Since the results of the tests in my home office seemed conclusive, however, I decided that field tests would be redundant.

Actually, under average conditions, the modem appeared to have no trouble providing error-free transmissions to a variety of systems over a reasonable level of external sound. As long as you avoid loud, sharp noises during transmission, Le Voyager MV 214 provides flexible telecommunications power in a small package.

Le Voyager MV 214 $390

COM 1 DATA COMMUNICATION 5120 Avenida Encinas, Ste. C Carlsbad, CA 92008 (800) 289-2661