Walk into any DP shop in America and here's what you'll see: rows of programmers sitting at terminals waiting for their compiles to finish, waiting for their links to finish, waiting for their test runs to finish. Is this any way to earn a living? 75% of programming consists of nursing mundane jobs through the system in order to correct the next round of bugs in your program and think up the next set of instructions you forgot to code in the first place. Correcting and thinking are noble tasks, but spending hours hitting ENTER just because the computer goes BEEP causes nail-biting and premature burn-out. In fact, many of these tedious steps could as easily be performed by a robot. Or a computer program.

In the early 70's, along about the time that Conversational Remote Job Entry (CRJE is pronounced "Kridgie") was liberating programmers from airless keypunch rooms, some of the larger minds at IBM began looking the problem of terminal fatigue (which was as much of a fact of life then as it is a pun today). If jobs submitted on cards could call up a number of programs in sequence using OS Job Control Language, why couldn't a programmer sitting at a terminal invoke a whole series of commands with a single supercommand? So they invented a new kind of file called a "command list", or CLIST. This file was nothing more than a list of commands, one per line. If the file was named LIST1, then "LIST1" became a new supercommand whose function was simply to issue the commands contained in the LIST1 command list.

With the arrival of TSO and down the ensuing years, CLISTs have begun to take on more functions. The addition of parameter passing, conditional command execution, branching, subroutines and external command list invocation, have made CLISTs now look more like programs than data files. And in fact, that's exactly what they are. The CLIST Language, Job Control Language, and VM/CMS EXEC Language, are all examples of interpreted command languages that partially automate the role of the programmer in shepherding work through the system.

Now for the good part. One of the things most irksome to professional programmers about the IBM/PC has been the lack of a really powerful CLIST or EXEC language. A primitive facility called "batch files" was included with DOS, but for most of us this was a throwback to CRJE, and nothing to get worked up about. DOS 2.0 teased us with such functions as branching (GOTO), conditional execution (IF), and an offensively illogical kind of variable manipulation called SHIFT, but for old-timers the promise seemed again more than the delivery. Now, finally, someone has solved the problem, and it's neither IBM nor MicroSoft. A new "freeware" package called Extended Batch Language (EBL), written by Frank Canova and distributed by Seaware Corporation, implements a command list facility so powerful that you can create multi-level menu drivers with it and even write simple games. Best of all, it can actually read the screen and type on the keyboard. How much more can real programmers do than that, aside from eating Szechuan food?

EBL Version 2.0 statements are imbedded in standard DOS batch files, and look suspiciously like CMS EXEC statements. Here's an example of a batch file written in EBL:

First of all, most EBL statements begin with the word "bat". This is the hook into the system, since BAT.COM is in fact where all the code is kept. Once the first BAT command takes off, it initializes its resident portion, and then reads and executes the rest of the EBL statements and DOS commands in the file. Subsequent EBL statements must also begin with the word "bat" to distinguish them from DOS commands, but they don't incur the expense of reading in the BAT.COM file all over again. EBL turns out to be quite fast. Let's look at each line: bat * Offer to play CHESS with the human...

This is just a comment. This .BAT file will look for a CHESS.BAT file and, if found, offer to play chess. If accepted, it will then pass control to CHESS.BAT. You might include logic like this as part of your AUTOEXEC processing to simplify booting when you're in the mood for a game. Just insert the chess diskette in the b: drive, fire up the machine, and the computer would seem to anticipate what you had in mind. bat stateof chess.bat

This checks for the existence of the CHESS.BAT file on any drive (but only the current path if you're using DOS 2.X), and sets the variable %R to reflect the result as follows: 0 - file found on default drive 1 - file not found 9 - illegal filespec

Cleverly enough, if %R is none of these, then it will have been set to the drive letter (a through d) the file was found on. STATEOF supports filespec wildcards, too. bat if %r = 1 exit

If file not found, leave the .BAT file. Other relational operators include >, <, and <>. bat if %r <> 0 %d = %r:

If the file was found, but not on the default drive, save the letter of the drive it was found on (concatenated with a colon) in the variable %D. Notice that THEN isn't required with IF. Also, since variable names can only be one character in length, string concatenation is a simple matter of pressing the strings together regardless of whether they're variables or literals. bat type How about a nice game of \0fCHESS\07? ;

This line prints a message on the screen. The hexadecimal numbers following the backslashes provide screen attribute information, in this case highlighting the word CHESS, while the semicolon suppresses a line feed so the cursor will stay near the question mark. bat inkey %k | type %k

Mainframes don't provide character by character interaction with terminals, so users of TSO CLISTs and CMS EXECs must hit ENTER to register their responses. EBL's INKEY function is patterned after MicroSoft BASIC, which takes advantage of the fact that you have the whole computer to yourself. The next key pressed on the keyboard will be assigned to the %K variable. (Special keys can be sensed by comparing them to special literals having a format of KEYxxx, where xxx might be 01b for the ESC key for example, or 147 for the HOME key.) Note the use of the command concatenation symbol "|" to group related commands. This is useful in IF processing since all concatenated commands are executed on the same condition. TYPE is used here simply to reflect the user's response back to the screen. bat if %k = y stack %dchess | stack n | stack 24

This statement checks the user's response. If "y" was pressed, three lines will be placed in the "keyboard stack". The keyboard stack is a concept borrowed from CMS and refers to an area in storage where responses to upcoming reads to the terminal are stored prior to their being requested. If %D is set to "b:", for example, the three lines stacked when %K = y will be: b:chess n 24

These lines are available to any program that reads from the terminal, including DOS itself when looking for the next command! Thus, when the current batch file is finished and DOS wants more work, it'll find "b:chess" when it issues a read to the terminal, and proceed to execute the B:CHESS batch file. The next two stacked lines are hypothetical responses to questions from the chess program. The ability to use EBL to answer questions you know a program is going to ask makes program initialization and parameter setting much less tedious than it usually becomes after awhile. If necessary you can also erase the stack with a STACK.PURGE, or merely defer it with a STACK.OFF followed later by a STACK.ON.

One feature of EBL that goes beyond anything that mainframers have is the ability to "read the screen". The READSCRN function reads the words from the previous line into variables that you name. Each successive READSCRN reads up the screen, and also sets %R to the number of the line you've just read so you don't accidentally go beyond line 1. Thus you could read messages from a compiler, for example, and go on to the LINK command only if the last message was "0 ERRORS FOUND"!

Other functions of EBL include:

• BEEP:>Sound the alarm.
• CALL:>Call a section of the batch file, which subsequently RETURNs.
• CLS:>Clear the screen.
• SECTION:>Unconditional branch. Labels begin with hyphens and can be 15 characters long, such as -LINK.THE.PROG.
• READ:>Read an entire line from the keyboard (which benefits from the availability of all the editing keys), and set zero or more variables. Optionally TYPE a message first (you can do this with INKEY too).

Variables are divided into DOS variables (%0 thru %9, which can be set as well as read) and "global user variables" (%A thru %O). Any variable can be up to 15 characters long. User variables are called global because they retain their values after the batch file has exited, and can therefore be examined by any subsequent batch file which refers to them by name.

Besides the %R system variable mentioned above (which can be set by any program by modifying the byte at 0:4FE), you also get: %Q:>"S" if there are lines in the stack, else "K" (for keyboard). %V:>the current default drive (a single letter). %S:>a single space, used to imbed blanks in variables. %%:>a single percent sign.

Assignment statements come in several flavors, too. Aside from the garden variety illustrated above, you can perform nullification (%a =), and simple arithmetic using the standard +, -, / and * operators (as in %a = %b + %c). As if that weren't enough, you can also do length detection (%a = %b # means "Assign to %a the length of %b") and substring extraction (%a = %b $ 1 3 means "Assign to %a the first three characters of %b"). These last formats become essential for advanced applications.

For a small one-time charge Seaware lets software developers include EBL batch files with their packages. So besides delighting legions of aging programmers writhing in various phases of flame-out, this facility should do much to alleviate the smarting of new users who open their brand new $900 copy of A-B-C only to find three days of one-time setup procedures to endure.

Extended Batch Language should be in the libraries of most computer clubs and dial-up services soon, but if you can't find it, send $30.00 to: Seaware Corp. P.O.Box 1656 Delray Beach, FL 33444

For your $30.00 you'll get a diskette containing the latest program version, online demo and tutorial batch files and useful utilities, plus a 70-page manual with descriptions, examples and tips. You'll also learn how to dial in to a special bulletin board service where you can share the merry musings of a large community of EBL users.

The kind of software that simulates the behavior of a computer user has slowly evolved over the last twenty years from lowly command-line storing facilities like DOS' batch files to brainy keyboard emulators like Prokey. Alpha Software, maker of Keyworks Advanced — the former top dog in this food chain — has now developed what must be the mother of all macro processors: a massive engine entitled Resident Programming Language.

Like its forerunner, RPL can record macros on the fly, playback macros with fill-in-the-blanks sections, present menus to the user, act differently depending on what it sees on the screen, and assist the beginner in keying in macro source code. But in addition, RPL macros can access machine registers, trigger DOS interrupts, simulate the pressing and releasing of individual shift keys (useful in calling up SideKick, for example), do I/O to text and dBase files, and (if you have the Mainframe Edition) interface to 3270 emulators. The RPL language has a much cleaner syntax, several new data types, and dozens of new constructs that make it easier than ever to fashion new interfaces to old programs using menus, pick lists, file selection dialog boxes and data entry forms.

When RPL is resident it monitors all keyboard, screen and timer events. Your programs can tell RPL to establish up to ten "event traps" and identify which RPL routines they will trigger. Thus you can tell RPL to type "PC MAGAZINE" when the user presses CTRL-F5, or sound an alarm whenever "ERROR" appears in the upper right corner of the screen, or toggle into DesqView's communications window every two hours. Through the use of the ShellExec() command, RPL can schedule a program every time an application exits and you return to the command line. The DosExec() command allows you to suspend any application and run another DOS program (even COMMAND.COM). You can also press CTRL-PLUS at any time and bring up RPL's development shell, from which you can do all your program maintenance.

The resident command interpreter is very fast, having been written in assembler. The development shell — which includes a program editor, help system, calculator and many utility functions — is written in RPL itself and therefore slower. But since source code is included with the product, this turns out to be a terrific way to learn the language.

Parsed RPL programs can be saved in run-time libraries, and up to ten such libraries can be active simultaneously. A debuging facility allows you to watch variables as their value changes. Text file I/O commands correspond to the familiar DOS Int 21 functions. Database I/O commands access the dBase .DBF, .NDX and .DBT file types. The lavish online help system indexes each language element by name, topic and type (ie. command, library procedure, flow-of-control instruction, system variable, parser directive, functions and operands). But you can also look up C, BASIC or KEYWORKS functions with which you are familiar and instantly cross-reference to their RPL equivalent.

If you have expanded or extended memory, RPL's TSR code will only claim 36K of memory (40K for the Mainframe Edition), about half what Keyworks eats. Reducing RPL's buffers can bring this number down even further. RPL understands not only Microsoft's HIMEN.SYS but competitors like QUEMM-386, too. RPL operates safely in Windows (386 Enhanced Mode) and DesqView sessions; it must be loaded separately in each application, though, and cannot be shared across sessions. The RPL documentation is both superb and immense, more than twice that for Keyworks. And, sadly, you'll need it, since this is not a product you can master merely by playing for a few hours.

A Mainframe Edition allows developers to program their 3270 emulation sessions via the Hllapi() command, which interfaces to IBM's High Level Language API (HLLAPI) for PC 3270 boards. The _Emulator% variable tells your program if a mainframe emulation session is in progress, and the more than 30 distinct HLLAPI subfunctions allow the mainframe screen to be read, searched or written to, the cursor position to be read and set, and keystrokes to be emulated. Alpha currently recommends Attachmate and Irma emulation software since it does not yet work with IBM's PC3270.COM program.

Although the new functionality makes a stab at CUA compliance, Alpha hasn't done their homework else they would never call PullDown() the function that creates across the first line of the screen what IBM calls an "action bar." And Alpha has ironically locked out their existing customer base by not providing a utility to migrate all those old Keyworks macros to the new RPL format. Since Keyworks and RPL can't both be resident, you'll have to do the conversion overnight or not at all. It's not unlike buying a new DBMS that can't import your dBase files.

Alpha could have made an easier-to-learn product by adding a few extensions to C or BASIC rather than inventing yet another brand new language. You'll be scratching your head over the fishy new array syntax, for example. But, carping aside, for anyone who wakes up each morning burning with new ideas on how to automate their PC work, and for those with unusual cooperative processing problems, RPL is definitely the new way to fly.