The Computer Journal, Issue 44
Z-System Corner
© Jay Sage
Reproduced with permission of author and publisher.
For this issue (and the next) I am going to indulge myself and write about something that I enjoy, even though, strictly speaking, it has nothing to do with Z-System. This subject is MEX-Plus, the most advanced telecommunications package available for CP/M computers. I suppose I could argue that there is a philosophical or spiritual connection, since MEX-Plus allows the user do for telecommunications many of the same things that Z-System allows one to do with the operating system, namely automate. In particular, I will be describing MEX-Plus's scripting capabilities, which are similar in some ways to alias and ARUNZ scripts in Z-System.
I had been hoping that a regular MEX column would develop here in TCJ, but that hasn't happened. Two of the people who might have gotten it going, Bruce Morgen and Rick Charnes, are now employed in the MS-DOS industry, and, after programming all day professionally, they don't seem to have as much energy left for hobby computing as they used to. Recently, David Goodenough, author of the QTERM telecommunications package, came over to my house and got QTERM running on my SB180 with its Wyse 50 terminal. I am enormously impressed with what David has accomplished with this program; it is rapidly developing many of the capabilities of MEX-Plus. I can envision much discussion in the future of both MEX-Plus and QTERM scripts. You can also expect an article or two about QTERM.
For this column I will give an overview of MEX's command structure, and next time I will describe in detail my suite of scripts for using PC-Pursuit as an example of what can be done using those commands. (I originally planned to cover both in one article, but after finishing the description of the commands, I was already at my limit.) Along the way I will try to point out some of the bugs and idiosyncrasies that users have discovered in MEX commands and suggest means to get around them. I hope that my examples will help give others ideas about how to make better use of MEX-Plus. Although regrettably I have had very few takers in the past, I again extend an invitation to readers to send me suggestions and examples for scripts.
Overview of MEX Commands
The original CP/M telecommunication program MODEM7 and its derivatives, such as IMP, operate in two modes: terminal mode and command mode. Terminal mode is used for talking to the remote system, while command mode is used to control the local system. These programs have a relatively small set of commands falling principally into two classes: those required for file transfers and those related to the setup of the program.
In MEX-Plus the arsenal of commands is extended enormously, and anything that could be done from terminal mode can be done from command mode as well. (You would not want to run an interactive session this way, but it could be done.) There are so many commands that, though I will mention almost all of them, I will not be able to explain them all in detail. Rather, I hope to give you a general picture of the kinds of tools one has to work with in MEX-Plus. I will take up the commands in groups.
Setup Commands
Most of MEX's configuration is controlled by three commands: STAT, SET, and TSET. The STAT command works with more than 50 different options! All of them can display information about how the system is configured, and all but a few also allow the configuration to be changed. The MEX STAT parameters fall into four classes: switches, characters, values, and miscellaneous.
Switches have values of ON or OFF. One example is FILTER, which controls whether MEX will filter from the incoming modem stream any control characters other than tab, backspace, carriage return, and linefeed. If one wants to perform full screen operations, this filter must be off. Otherwise, the escape characters that initiate a screen control sequence will be swallowed by MEX.
Character STAT parameters take a single ASCII character as their value. An example is SEP, the multiple command separator (like Z-System, MEX-Plus allows multiple commands on a line). Value parameters take on numerical values. For example, PAGE sets the number of lines in a page on the screen, and CLOCK is set to the clock speed of your microprocessor chip so that timing delays will come out right. The miscellaneous STAT parameters mostly control the display of groups of information. "STAT ?" lists all the STAT parameters; "STAT VAL" shows the value parameters.
The SET command controls the modem setup. It is used for setting the baud rate, word length, number of stop bits, and parity mode. The TSET command was one I never used until working on this article. It controls special features related to the terminal (what is does depends on the terminal you are using). With my Wyse 50, a TSET parameter can force all characters to be displayed in upper case characters or in highlighted video (that should give you some idea of why I have never used this command).
Operating System Commands
Another group of commands deals with the interface to the operating system.
Naturally, there has to be a way to get out of MEX and back to the operating system prompt. Have you ever been trapped inside a program, not knowing how to exit? Well, MEX author Ron Fowler must have had such a harrowing experience, because he has six (count 'em!) commands for getting out: BYE, EXIT, QUIT, CPM, DOS, and SYSTEM. SYSTEM must come from BASIC, which is the only CP/M program I ever became trapped inside. MEX-Plus is available in an MS-DOS version as well, and that is where the exit command DOS comes from. As a CP/M diehard, I take great pleasure, as you can imagine, in exiting from my DOS version using the command CPM (it doesn't help - I'm still in MS-DOS after I exit).
There are commands for doing operating system chores: DIR, REN, ERA (or, following MS-DOS, DEL), TYPE, and LOG (change drive/user). Some of these commands not only perform their functions; they also return information for use in a script file. DIR, for example, sets a special variable to the number of matching files found, and thus can be used to determine whether a particular file exists or not.
There are the commands KEY for associating strings with any ASCII key on the keyboard and PHONE for entering phone numbers into a dialing library. The key definitions and phone number library can be stored in disk files with the respective extensions KEY and PHN. The commands SAVE and LOAD write the data to and read the data from the files.
MEX-Plus has a facility, via the INSTALL command, to load optional extra code modules. One such module (the REMOTE module) allows MEX-Plus to be operated as a remote access system. I have used this with both direct wire and modem connections between machines. The former is handy when two machines are connected by a cable, as it relieves one of the need to run back and forth between the two keyboards to issue file transfer commands. I sometimes leave my system at work in remote mode so that I can call it from home to pick up a file that I forgot to take with me. Other optional modules support emulation of various terminals, including the VT100.
The TERM and TERMA commands open a file to record the incoming character stream from the modem. TERM creates a new file, while TERMA appends the new text to an existing file. The terminal mode commands T, L, and E described below can also take an optional 'A' suffix and capture file name. In those cases, once the capture file has been opened, MEX is put into terminal mode. The TERM and TERMA commands leave MEX in command mode for further script processing.
The VIEW command allows the contents of the capture file to be reviewed while online, thereby affording some scroll-back capability (that is, a way to see text that has already scrolled off the screen). WRT closes the capture file (saves it) when you are done; DEL discards it.
The ALT command specifies an alternate drive/user area (in addition to the currently logged one) where MEX can search automatically for files (e.g., scripts, phone directory, etc.). The SEARCH command tells MEX how to go about searching for files, such as whether to search the alternate area before or after the logged area.
As you can probably guess already, it is not easy to remember all these commands and the syntax they require. That is where the HELP command comes in handy. It accesses an extensive HLP file (over 70K). There is also the wonderful CLONE command, which creates a new version of MEX (i.e., a new COM file) with the current configuration embedded - after the STAT, SET, TSET, and other commands have been used to change parameters to one's liking.
Telephone Interface Commands
MEX-Plus has two phone-dialing commands, CALL and DIAL. Both accept lists of either literal telephone numbers or names from the phone library. Numbers and names may be mixed. Numbers in the library may have associated baud rates, which will be selected automatically when that number is dialed. An optional parameter specifies the number of times to try connecting to the numbers before giving up, and the commands return a value to indicate which number, if any, was reached. Here is an example:
CALL LADERA 617-965-7259 #3
This will alternately called the Ladera Z-Node (whose number is in the library) and my Z-Node up to three times before giving up . The commands differ in that CALL puts one in terminal mode after a successful connection, while DIAL leaves one in command mode for further script processing.
There is also a way to get out of a connection. DSC will tell the modem to drop the connection. It can be configured (using a STAT command, of course) to use either the DTR (data terminal ready) hardware control line or the Hayes AT hangup command.
Terminal Commands
There are three commands for entering terminal mode. The command T (terminal) sets up a full-duplex terminal mode. Characters typed at the keyboard are sent to the modem; characters received from the modem are sent to the screen. If you are to see what you are typing, the remote system must echo back the characters it receives from you. Most microcomputer BBS systems do that.
The L (local echo) command sets up a half-duplex terminal mode . The difference is that the characters that you type are not only sent to the modem for transmission to the remote system; they are also echoed locally. This mode would be used with systems like GEnie that do not normally echo the characters they receive from you.
Finally, the E (echo) command sets you up as if you were a remote host. Every character you receive is then echoed back to the modem. If two people running MEX call each other (or two machines are hooked up by cable as I mentioned earlier), either both should be in L mode, or one should be in T mode and the other in E mode. I prefer the latter, since seeing the characters on the screen of the machine in T mode assures that the connection is working. I leave it as an exercise to the reader to figure out what will happen if both machines are in E mode. (Hint: feel free to experiment; you can get out of the infinite loop by exiting from terminal mode; you don't have to reboot.)
File Transfer Commands
Files are sent to the other computer using the S command, and received from the other computer using the R command. MEX-Plus supports three file transfer protocols: KERMIT, XMODEM, and YMODEM. The default protocol is set with the PROTO command. The protocol can also be specified explicitly using a prefix (K, M, or Y) to the S or R command.
The commands will also accept any of several suffixes as well. The suffix B indicates a batch-mode transfer. The K suffix with the S command indicates that the file should be sent in blocks of 1K bytes instead of the standard 128 bytes. If you append T, L, or E, you will return to the corresponding terminal mode after the transfer is completed. The D and X suffixes will tell MEX to disconnect from the remote system after the transfer is finished; with D you will return to MEX, while with X you will exit MEX as well. Here is an example.
YSBKX FILE1 FILE2 FILE3
This will send the three files using YMODEM batch with 1K blocks, hang up the phone, and exit from MEX.
Transactions with a host in the KERMIT server mode are supported with a number of special commands (KGET, KPUT, KBYE, KLOG, KFIN).
Video Commands
These are the commands that Rick Charnes loves so! There are commands for cursor addressing (@), beginning and ending the use of up to four video attributes (START and END), displaying special line-drawing graphics characters (DRAW), and creating lines and boxes (HLINE, VLINE, BOX). The screen can be cleared (CLS). It can also be turned on and off (SCREEN) so you can control what output is seen and what is not.
Variables
It is hard to do very sophisticated processing without variables. MEX-Plus offers variables of two types: numerical and string. The former are 16-bit integers (i.e., numbers from 0 to 65535); the latter are strings of up to 32 characters. There are 26 numerical user variables designated by a percent sign followed by a letter (case does not matter, e.g., %a or %S). There are six string variables designated by the letters A through F. I've never run out of numerical variables, but I sure wish there were more string variables.
There are also two special numerical variables called VALUE and STACK. The former is used to hold the value returned from a number of MEX commands (DIR and DIAL/CALL were mentioned earlier). STACK is a more long-lived variable that can be exchanged in various ways with VALUE (the commands PUSH, POP, and XCHG). I think these are left over from earlier versions of MEX that did not offer the 26 user variables. There is little reason to use STACK any more. There are three special operations (ADD, SUB, and XOR) that can be performed on the VALUE variable. I've never found any use for these, either.
MEX can evaluate arithmetic expressions consisting of combinations of literal numbers, numerical variables, and arithmetic operators (+-*/). Here is an example that returns the least significant byte of the two-byte variable %V:
%V - 256 * ( %V / 256 )
Numbers can be entered in hexadecimal format by prefixing the number with a dollar sign ($100 is 256).
The value of an expression is assigned to a variable by the equal operator (=) as in %B=%A+3. NOTE: in most places in MEX-Plus, extra spaces may be included in command expressions. However, there are unfortunately a number of bugs in MEX-Plus, and some rear their heads in this area. Therefore, I recommend that extra spaces be omitted in working scripts (as opposed to fully commented reference versions, where extra spaces might be included to improve readability).
Literal string expressions are composed by surrounding text with double-quote characters ("). The MEX manual says that values are assigned to string variables using the STORE command as in:
STORE "this is a test" TO A
Experiment shows that the following simpler, undocumented syntax also works: A="test". Here I know from bitter experience that there should be no extra spaces around the equal sign. It often works, but not always. Most commands that accept quoted literal strings will also accept string variables (e.g., B=A or COMP A "yes").
Command line parameters are also available to scripts; they are passed in the form of variables represented by the numbers 1 through 9 surrounded by curly braces. These variables can always act as strings. If they express a number, they can also be used as numerical expressions. Thus, we might have A="{1}" or %A={1}. The latter expression will produce an error if the first command line token do es not represent a number.
If the script invocation command line does not have a token referenced by an expression of the form {1}, {2}, etc., the script will bomb with an error message. The expression {n:default) allows a default value to be used for parameter 'n' if none is given on the command line. This default value can be null, as in {1:}. String variables can, like the command line tokens, be represented in expressions by curly braces around the letter (e.g., {B}). In such a case, the value of the expression is the string of characters alone, and double quote characters must surround the expression in most situations. There are exceptions. The SAY and SENDOUT commands (described in the next section) can be used directly with a variable, as in SAY A. The following two commands are equivalent:
SAY "Variable A has the value: ",A,"/n"
SAY "Variable A has the value: {A}/n"
The curly-brace expressions can be used to concatenate text, as in
A="{B} and {C}"Expressions of this type are not documented and work only in script files; they will not work if entered directly at the MEX command prompt. Similar expressions can also be used to finesse variables into commands that normally do not take them. Here are some examples:
set baud {b} (where, say, B="1200") set baud {c}00 (where, say, C="24") goto {1} (where, say, token 1 is LOOP) {a} (where, say, A="set baud 1200")
I have not figured out how to split a string variable into parts (such as words). I also had never been able to figure out a way to convert a numerical variable into a string. I still can't do it directly (things like B={%B} do not work), but the script in Fig. 1 does it indirectly (inventions like this are part of the fun of writing this column). You may not be able to fully understand that script until you have read through the rest of the command descriptions.
B="" initialize to null string
%y=%b set up scratch variable %y
LABEL LOOP loop
%x=%y-10*(%y/10) get the lowest digit ( %y MOD 10 )
if %x=0 B="0{B}" preconcatenate the appropriate digit
if %x=1 B="1{B}"
if %x=2 B="2{B}"
if %x=3 B="3{B}"
if %x=4 B="4{B}"
if %x=5 B="5{B}"
if %x=6 B="6{B}"
if %x=7 B="7{B}"
if %x=8 B="8{B}"
if %x=9 B="9{B}"
%y=%y/10 divide number by 10
if %y>0 GOTO LOOP continue until number is reduced to 0Figure 1.
Commented listing of a script that will convert the numerical variable %B into string form in string variable B, from which it can be used in various commands, such as: SET BAUD {B}. This code could be made into a subroutine by adding the command PROC NUM2STR at the beginning and ENDP at the end. If you try this script, do not enter the comments, of course.
Input/Output Commands
Programs generally are not terribly useful if there is no way to get data in or out. Here is what MEX-Plus offers.
The SAY command allows one to send characters to the screen. It accepts arguments of literal strings, string variables, and numerical expressions, as in
SAY "The sum is",%A+%B,"/n"
There are special character codes, such as "/n" (newline) or "/r" (return). Combined with the video commands mentioned earlier, the SAY command can produce some pretty fancy displays.
There is also the undocumented PRINT command that does almost exactly what SAY does, except that it does not need quotation marks around the literal text and does not interpret any special expressions. To PRINT, everything is a pure string. There are, thus, a couple of things PRINT can do that SAY cannot. Here are some examples:
PRINT Please enter "Hello" at the prompt.
PRINT Use the expression {1} for a token.
In the first case, PRINT allows one to send a double quote character to the screen. In the second case, a string that would be a variable expression can be displayed.
The SENDOUT command is used to send literal text or the contents of string variables to the modem. The PREFIX and SUFFIX commands can be used to define strings that are automatically sent before and after the designated text to save one the trouble of having to include certain characters (such as, perhaps, a carriage return and linefeed) explicitly with each string. Longer, fixed strings can be sent using the TRANSMIT command, which sends the contents of a file just as if you were typing it in terminal mode. A pair of delay constants controls the speed with which this "automatic typist" performs.
The INPUT command allows interactive entry of the value for a numerical variable; ACCEPT does the same thing for a string variable. The TIME and DATE commands allow one to access a real-time clock. Besides displaying the information on the screen, the commands are supposed to put the corresponding data into the VALUE variable. There is a bug here, and the time value is used by both commands. There appears to be no way to determine the date from within a script. The PEEK and POKE commands allow one to look at and modify memory for the ultimate in hacking from a script! (That probably means that there would be a way to find the date if one really needed it badly. It also means that the complete Z-System environment can be accessed.)
Flow Control Commands
Like Z-System, MEX-Plus has flow control commands to allow a script to perform tests and to act differently depending on the results. There is the standard set of flow commands IF, ELSE, and ENDIF. They support 8 levels of nesting (just like Z-System). Here is an example:
IF %B=1200
B="1200"
ELSE
B="2400"
ENDIF
Additionally, there is a single-line IF command. It is distinguished from the multiple-line IF by a command (a 'then' clause) that is part of the IF statement. Here is an example:
IF %B=2400 B="2400";SAY "2400 bps";GOTO CONTINUE
With the single-line IF, when the test fails, the entire line is ignored. Please note that had there been a semicolon after the "IF %B=2400", then this would have been a multiple-line IF (albeit with several of its 'lines' on one line).
The single-line IF command comes in especially handy, because it is generally awkward to perform a GOTO jump out of an IF/ELSE/ENDIF block. Although the manual warns against it, there is (I'm pretty sure) no harm perse in doing it. It is just that you have to make sure that the ENDIF is not skipped lest you get nested deeper and deeper. As with Z-System, you have to make sure the IFs get terminated; unfortunately, this is not so easy, because, unlike Z-System, MEX-Plus has no XIF or ZIF command. Here is a very convoluted example of a way in which it could be done:
if %b
say "TRUE/n"
goto cont
endif
.
say "FALSE/n"
goto done
.
label cont
endif
.
label done
say "Now we are done/n"
There is also a SKIPIF command. If its test is true, then the next command is skipped. Note well that while the IF command may skip an entire line of commands, SKIPIF skips only one command, no matter how many commands may appear on the same line.
Numerical Tests
Flow control would not be very useful without ways to test things. First we will consider tests on numbers.
Test results are expressed numerically, with 0 representing false and non-zero (usually 1) representing true. You can see this for yourself by entering the command "SAY 1<2" or "SAY 1>2". The following logical operators can be used for comparisons: equals (=), not equals (<>), less than (<), less than or equal to (<= or =<), greater than (>), or greater than or equal to (>= or =>). Note that the MEX manual has a misprint in one place and gives the not-equal-to operator as '!'. That is incorrect and will not work.
Although comparison tests return a numerical value, those values for some reason cannot be used in arithmetic expressions. In other words, you can't have (%A>%B)*(%A<%C). As far as I can tell, this means that you cannot perform compound tests, such as "IF %A>%B AND %A<%C". Performing such compound tests is made more difficult by the fact that the 'then' clause of a single-line IF cannot be another IF. If you won't be using GOTO, nested multi-line IF commands will do the trick. Otherwise, you might have to resort to some explicit arithmetic as in the following:
%z=1
if %a<=%b then %z=0
if %a>=%c then %z=0
if %z then ....
We started out assuming TRUE (%z=1). Then if either condition was false, we set %z to false.
Before we leave this topic (I know we've been here a long time), I have to mention that MEX has a bug that causes it to issue fallacious but very annoying error reports when comparison operations are performed with numerical variables having particular values. I have carried out a number of experiments to try to determine the exact circumstances under which this problem occurs, but so far I cannot fathom a pattern. The trouble often appears, however, with comparisons to standard data rate values, such as 300. To get around the problem, I sometimes divide the variable by 100, compare it to 3, 12, or 24, and then multiply it by 100 to restore its original value. What a pain!
String Tests
Strings are compared using the COMP command. It accepts two strings, each of which can be either a literal string or a string variable. The result of the comparison is returned in the VALUE variable, which can then be tested for a value of 0 or 1. The STAT CASE setting determines whether the comparison will be case sensitive or not. There is a bug with the COMP command; it will not give the answer 1 (true) when both strings are null (""), though it will work if only one string is null. If you want to see if a command line token was given, you can use the following tests:
COMP "{1:} " " "
COMP "{1:}X" "X"An extra character (space or 'X') is concatenated to the string represented by {1:}. You might also use
COMP "{1:null}" "null"Here, the first parameter cannot be null. If token 1 is not given, the default value "null" will be used instead. Of course, if the user enters "null", the same result will be obtained. The two earlier examples are, thus, more robust.
There is one oddball command that I don't know where to put: SLEEP. It is sort of a flow control command, so I'll stick it here. It just tells the system to go to sleep (pause) for a designated time interval.
Program Control Commands
MEX-Plus supports several script program structures. The main unit of a script program is a script file, which has a file extension of MEX. It can be invoked as a main program by the READ command. It can also be invoked as a subprogram by the DO command, which allows scripts to be nested. I do not know how deep this nesting can be, but I just tested it to five levels. The STOP command is used to exit from a READ or DO command. In the former case, control returns to the MEX program (possibly in terminal mode); in the latter, control returns to the script that called the current script. A script also terminates automatically at the end-of-file. The STOP command unfortunately displays an annoying message about the script being aborted. To exit gracefully, it is better to put a label at the end (e.g., LABEL END) and to exit using GOTO END.
A READ command may be given inside a script. In this case, control is transferred to the new script, which overwrites the old script in memory. With the DO command, the new script lines are read into memory along with the currently running script. I always enjoy writing these columns because I end up asking some new questions and learning some new answers. Just now, to see how MEX works, I was examining the memory image after a MEX script file ran. First, I learned that the script text is stored backwards in memory starting from near the top. I verified that after each DO is finished, the memory is reclaimed and is available for use by another subroutine script. I also discovered that the entire script file, including all comments, is read into memory.
We can draw some important conclusions from these observations about how complex scripts should be implemented. First, there are several advantages to using versions of script files from which comments have been stripped. The files will, of course, load faster, and there will also be more room in memory for such things as file transfer buffers. Many MEX users have run into problems of insufficient memory while running complex scripts. Second, it is a good idea to chain from one script to another rather than building everything into a single script. In my PC-Pursuit script, I chain to a very small script just after the remote system has been reached and the script is about to put me into terminal mode.
Structure is permitted within an individual script file as well in the form of internal subroutines. Subroutines begin with a PROC (procedure) command and end with an ENDP (end-procedure) command. They are invoked by the GOSUB command. Again, I do not know how deeply they may be nested, but I just tested them to 9 levels.
Script files may also contain unstructured program groupings (that anathema to modern structured programming). The LABEL command allows any point in the script to be given a name, and the GOTO command allows a branch to that point. The manual indicates that the name may have up to 16 alphabetic characters and warns that the line with the LABEL command may not have any other commands on the line. I know that I have run afoul of that restriction in the past, but, oddly enough, in my testing now I was totally unable to generate a problem. I tried everything I could think of: an immediate semicolon, a semicolon after a space or a tab, tabs after the semicolon. They all worked just fine (how could MEX tell that this was just a test?).
The manual is clearly wrong when it says that only alphabetic characters can be used. I assumed that it really meant alphanumeric, but in my experiments I learned that absolutely any characters can be used, including spaces! Here are the rules that emerged from my testing. First, all spaces and tabs after the LABEL command are ignored. That point marks the beginning of the name. Next one starts from the end of the line or the command separator character and strips all tabs and spaces backward. That point marks the end of the name. What is between those marks is taken as the label.
For example, one can have a label of "ENTRY 1" (with the embedded space and with or without the quote characters, in fact). Mind you, I am not by any means suggesting that you use such labels. As I mentioned before, I have not always found MEX to behave exactly the way it did in these experiments. If anyone can figure this out more precisely, I would really like to hear about it.
The other thing I learned from these experiments is that MEX always scans for a label from the beginning of the script. This means that if you use the same label a second time, the second occurrence will never be found.
One Script Example
I just don't feel right about presenting all this information about MEX-Plus commands without showing at least one real-life example. Figure 2 shows the final script in my PC-Pursuit script suite. Once I have successfully connected to the outdial city and reached the remote system there, I chain to this script. Let's look at it line by line.
The first line begins with a period, so it is a comment. I always include a title line and often add some description of the function of the script and the parameters it takes.
The real work of the script begins at line 3. In many parts of the script, I do not want the output from commands to show on the screen. Now I do, so I issue the "SCREEN ON" command. I'd also like to start with a clean screen, so I issue CLS, too.
In line 5, the script tells the user the name of the system that has been reached (that was previously stored in string variable F) and at what baud rate (previously stored in string variable B). Then the script drops one into terminal mode, where one can work interactively as long as one likes.
When terminal mode is exited (by pressing <ESC> E), the script resumes at the label LOOP. Line 9 prompts the user to enter a command. If the user enters "M", then the main menu script is run, allowing one to call another system in another or the same city. Line 10 accepts the answer from the user and places it into string variable A.
In line 11, the user's answer is compared to the string "M". If it was "M", then the variable VALUE will have the value 1 (true), and line 12 will cause the script to chain to the script file PCPMENU.MEX. If the user entered anything other than "M", then execution will continue at line 13, where the user's command is executed. When that command has completed, control will return to line 14, which branches back to label LOOP and a prompt for another command.
The user's command can be just about anything. For example, if it is "T", then MEX will enter terminal mode for more interactive work. The one restriction I have found, is that only a single command can be entered. A multiple command line, with commands separated by semicolons (or whatever the designated SEP character is), does not work for reasons I do not yet understand. Maybe I will have figured it out (or one of you will have) by next time, when I will cover the real guts of the PC-Pursuit script.
01 .. PCPCONN SCRIPT -- Connected to Destination System
02
03 screen on
04 cls
05 say "Connected to ",F," at ",B,"00 bps/n/n"
06 t
07
08 LABEL LOOP
09 say "/nEnter single MEX command (or M for menu): "
10 accept A
11 comp A "M"
12 if value=1 READ PCPMENU
13 {A}
14 GOTO LOOPFigure 2.
This is the final script in my PC-Pursuit suite. Just after connecting to a remote system, I chain to this script to free up as much memory as possible for other uses, such as capture buffers and/or file transfer buffers. Line numbers have been added for reference purposes in the text.
[This article was originally published in issue 44 of The Computer Journal, P.O. Box 12, South Plainfield, NJ 07080-0012 and is reproduced with the permission of the author and the publisher. Further reproduction for non-commercial purposes is authorized. This copyright notice must be retained. (c) Copyright 1990, 1991 Socrates Press and respective authors]