Oakland CPM Archive

home *** CD-ROM | disk | FTP | other *** search

/ Oakland CPM Archive / oakcpm.iso / cpm / mex / pcpfast.mzx / PCPFAST.MEX

Wrap

Text File | 1987-01-31 | 27.3 KB | 561 lines

+ -1- File: PCPFAST.MEX Rev: Jan 26, 1987 FAST AUTOMATIC PC PURSUIT CONNECTIONS USING MEX ----------ooooooooooOOOOOOOoooooooooo---------- by Laurence J. Lavins 1. P C P F A S T A B S T R A C T ---------------------------------- A simple user-friendly method has been developed for automatically accessing a PC Pursuit city, using the MEX v.1.14 PD communication terminal program, running under CP/M-80 (v.2.2). If a BUSY signal is received, the access string will be AUTOMATICALLY retransmitted every 5-6 seconds until a CONNECT signal is received from Telenet. The user may then send commands to the remote Telenet modem in the normal manner. This method does not involve any use of a keystring file, thus allowing the user to retain the entire capacity of that keystring file for other purposes. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2. I N T R O D U C T I O N -------------------------- Over the past few months, the number of customers using Telenet's PC Pursuit Service has increased dramatically, thus making it very difficult to place a call, especially during the few hours of peak system usage each day. As a consequence of the often prolonged, repetitive and wearisome transmissions which must be entered by a caller seeking to estab- lish a connection with a distant PC Pursuit city, some means were sought to facilitate this process. My own computer system is a modified TRS-80 Model 4 equipped with a hard disk, a Hayes compatible 300/1200 baud modem, and both the TRSDOS 6.2 and CP/M operating systems. With TRSDOS, I usually use the XT4 (v.1.6.8) communications terminal program (Copyright 1985 by Bill Andrus, Fairfax, VA). And with CP/M, my program of choice is MEX v.1.14 (Copyright 1984 by Ronald G. Fowler, Ft. Atkinson, WI). Both of these communication programs have many nice features, and they're both in the public domain for non-commercial private use. I understand that the authors of both these programs may now also have released other commercial or proprietary versions, with added features. Unfortunately, these aren't in the public domain. What I attempted to do, therefore, was to see if I could develop some rather simple means of adapting either of these two communi- cations programs to enable faster and/or more automatic means of establishing a PC Pursuit trunk connection to the called city. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - + -2- 3. T H E S P E C I F I C P R O B L E M ------------------------------------------ When making a call via PC Pursuit, it's first necessary to access a Telenet node by calling the local phone number of that Telenet node. This presents no problem. Almost all communications terminal programs now in wide use provide excellent capabilities for making such phone calls. Once a connection has been established with that Telenet node, however, the PC Pursuit caller must then request the system to set up a connection from that local node to a modem port in the city being called. Therein lies the heart of the problem. Since there may be hundreds of customers (callers) trying to gain access to some limited number of modem ports in any one of the 25 PC Pursuit cities, the usual response from the system is a "BUSY" signal. The callers must then keep calling, and as each port may become available, some lucky caller will be connected. Obviously, the more access requests a caller can initiate in a given period of time, the better will be his chances of getting connected. Unfortunately, this element of a call isn't a trivial matter. The Telenet protocol requires the following string to be sent out, in response to the Telenet network command prompt symbol, "@": "C DIALaaa/bb,uuuuuuuu,pppppppp" [cr] where: aaa is the Area Code of the city being called. bb is the baud rate in hundreds, either 3 or 12. uuuuuuuu is the User ID (usually 8 bytes). pppppppp is the Password (usually 8 bytes). Typing this string isn't bad once, or maybe twice. But just think what it would be like to manually enter such a string 100 or more times in succession! Well OK, you might say, all anyone has to do is to set up a macrokey, or function key, or whatever name your communications terminal program uses for such things. And both of my own two terminal programs, named above, certainly do have such features, as do most others in wide use today. I agree. Now we're much better off, not having to manually type in such long strings, over and over, repetitively. But I'm lazy. And I also get mighty fed up just having to keep on pressing [CLR] [KEY] or [ESC] [KEY], over and over, in response to each and every BUSY signal from Telenet. Even this, done 100, 150 or 200 times in rapid succession, is enough to drive me away from all this high-tech stuff, back to the wastelands of TV. Moreover, the XT4 program is limited to a maximum of 10 macrokey strings in each data file. Since I insist on using at least 5 of these for other purposes, then only a maximum of 5 are available in any one data file for these PC Pursuit city strings. Even then there's no capacity left for local phone numbers in those cities once all 10 keys are used up. So realistically, I'd have to put up with the continuous loading, back and forth, among 5 or more data files. Not too accomodating. MEX fares somewhat better in this regard, although it's not quite as convenient for general communication purposes as is XT4, in my opinion. Theoretically, MEX allows you to have as many keystrings in a single keystring file as there are keys on the keyboard. But - + -3- there seems to be a 404 byte limit on each such file, according to my arithmetic, which DOES include the two sets of quotes that MEX requires to define a string, but DOESN'T include the key symbols themselves and equal signs. So maybe you can put 8 or 9 of these city strings into each keystring file, using the rest of the 404 bytes for other commonly used strings, telephone numbers, etc. So now, with MEX, we're down to only 3 of these files. For example, PCP1.KEY, PCP2.KEY and PCP3.KEY. Not much of an improvement, but a little bit maybe. But it's still a crude approach to the problem. Another awkward option, of course, is not to prestore any of these city strings. But rather, to type them individually, as required, just prior to calling a PC Pursuit city, and then storing only that one string. The advantage of this, of course, is that you may then be able to get by with a single data file. But as far as all that continuous typing of 35 byte keystring sequences every time a new city has to be called ... . no thanks! And now, finally, that everyone understands that I really am quite lazy, the problem boils down to developing an easier, faster and more efficient means for dealing with these PC Pursuit city access calls, especially in the high-traffic busy hours conditions. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4. S E L E C T I O N O F M E X ---------------------------------- Despite my own personal preferences for XT4 over MEX for general communications purposes, I did decide, for a variety of technical reasons, that XT4 in its present form wasn't a suitable candidate for this exercise. Conversely, however, and also out of technical considerations, MEX seemed to offer some viable possibilities. So the remainder of this paper will deal only with MEX. I did, of course, reveal my little project to several of my close associates. The most profound advice and counsel elicited from all these experts was that I wouldn't ever achieve salvation until my obsolete "TRASH 80" machines were replaced by Big Blue or one of its clones. With a machine of such a color, and software to match, I was told, all problems such as this rapidly disappear. Or at the very least, I was also advised, if I insisted upon remaining loyal to CP/M (shudder!) why not just purchase the expanded proprietary version of MEX from Ron Fowler, which might be able to handle this class of problem. As a natural born rebel, I now became even more obsessed with the problem, and refused to stop thinking about it, and continued on, trying out several different approaches. So now we're down to the following ground rules: (1) A standard CP/M-80 (v.2.2) operating system. (2) MEX Version 1.14 PD release. (The earlier v.1.12 would probably do just as well for this application, however.) (3) Maintain a simple user-friendly approach, using inherent features of MEX and CP/M. Minimize changes & additions. (4) Nothing of a commercial or proprietary nature is to be utilized. Everything shall be in the public domain (PD). -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - + -4- 5. T H E B A S I C A P P R O A C H -------------------------------------- After much analysis of the MEX commands and stat variables plus a great deal of trial and error, it seemed like it might be possible to play some tricks on MEX, using the SENDOUT command and/or the READ command, along with some other associated commands and stat variables. What we'd like to do is to set up the equivalent of some logic of the "IF ... THEN ... " type. Now, it's quite clear that the PD version 1.14 of MEX doesn't include such sophisticated commands. Specifically, we need to do the following: (1) Pre-store a complete set of city access strings. Or as an alternative, a single string with symbolic variables. They should reside in a data file of semi-permanent nature. (2) Initiate the transmission of any one specified access string in a simple manner with minimum keystrokes. (3) IF a "BUSY" signal is received, THEN repeat the previous transmission after a network command prompt appears. This is to be done completely automatically, without the user's manual intervention, for some specified number of retrans- missions. The user should be able to abort this process at any time. (4) IF a "CONNECT" signal is received, THEN do not repeat the previous transmission, but rather allow the user to enter the data transfer mode and send commands to the modem at the distant PC Pursuit city, in the normal manner. At first glance, MEX 1.14 doesn't appear to support the commands needed to implement this logical sequence, but closer examination reveals that it does, in fact, have the capability. We'll have to perform some sleight of hand in order to fool the system, but it really can be done. Trust me! -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 6. T H E S P E C I F I C S O L U T I O N -------------------------------------------- Here's what we're going to do now to weave our bit of magic with MEX. First, the logical structure, then the details. In hindsight it seems so simple. So how come it took so long for someone to figure it out, dummy? -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 6.1 THE LOGICAL STRUCTURE -------------------------- The logical basis of the solution here is to use the WTECHO stat variable in conjunction with a SENDOUT command. When WTECHO is ON, all characters transmitted to the remote terminal (Telenet) via a SENDOUT command are compared with the characters echoed back from the remote. Since Telenet does echo back whatever we send out, as - + -5- any good host terminal should, that cooperation is what makes our trickery work. If there's a discrepancy (error) between what we've sent out and what's echoed back, then MEX further provides us with the means to retransmit. Not only must WTECHO be turned ON, but we must also specify a CANCEL character to be sent out to the remote upon discovery of the error, and also a TRIGGER character which we must look for from the remote to trigger our retransmission of the SENDOUT string. Lest I forget, the "error" character that's added to the SENDOUT string in order to create the discrepancy between the SENDOUT string and its echo in the first place, along with the CANCEL and TRIGGER characters are extremely critical and specific. It took lots of educated guesswork, plus trial and error, before a set of values for these 3 characters was found that would permit a completely workable solution. Unless all the values are set up in exactly the correct way, either one of the following may occur: (1) There may be no retransmission of the initial call after a "BUSY" signal is received. (2) There will be continued retransmissions of the original call as long as "BUSY" signals are received from Telenet. But then after a "CONNECT" signal is received, MEX will "freeze", and CP/M must be rebooted to restore your system. Additionally, the REPLY and RETRY stat variables should be set up properly, but these aren't critical. The "error" character mentioned above is a single character which is appended to the SENDOUT string IMMEDIATELY FOLLOWING the final "^M" carriage return in that string. My theory here, which proved to be correct, was that such a character would be saved by MEX for comparison purposes when WTECHO is ON, but that it wouldn't really be transmitted out via our own modem or echoed back by Telenet in the unlikely event that it did get transmitted. Since MEX has been designed to save the contents of the string prior to transmission, whatever they may be, for comparison purposes, that's exactly what we're now going to take advantage of for our own purposes here. So far, so good. Now let's go back to the SENDOUT string itself, which conforms to the format described back in Section 3. The way to make it simpler, at this time, is to execute PREFIX and SUFFIX commands as soon as MEX is booted up. Like this, for example: PREFIX "C DIAL" SUFFIX "//12,uuuuuuuu,pppppppp^Me" where uuuuuuuu is the User ID pppppppp is the Password e represents the appended error character To initiate transmission, just key in "SENDOUT aaa" for the area code of the city you're calling, and hit your [cr] key. The whole string, including the PREFIX and SUFFIX, will then be correctly sent out by MEX. Note that if a "BUSY" response comes back from Telenet, MEX logic will cause a retransmission, provided that all the appropriate stat values have been entered. Have patience now, we're still developing the logical structure. The specific values for the error character and those stat variables will be revealed below, shortly. - + -6- Now, if everything being done is clearly understood, let's go one step further beyond the basic SENDOUT command. This brings us to the READ command. It may appear to be a little difficult to grasp at first, but it's quite simple. Look at it like this: All we're doing is to take the SENDOUT command, along with its whole string (no need here for PREFIX and SUFFIX commands) and enter it into a file on disk. Let's use the default drive (usually A:), and also let's arbitrarily (because I say so) name this file P.MEX. You can use any old word processor or text editor of your choice to create and store this file. It'll look like this: File Name: P.MEX Contents: SENDOUT "C DIALaaa//12,uuuuuuuu,pppppppp^Me" See, nothing to it. The contents of this file are all included on a single text line. After you've saved this file on the disk, key in the command "TYPE P" directly from MEX, or "TYPE P.MEX" from CP/M, in order to verify that this file really contains what you think you wrote and saved. Since we used the MEX default extension for this filename, we don't need to use the extension when calling this file from within MEX. (Ain't that clever now, huh?) If you're still hangin' in there, don't let go. You've almost got both feet up onto this step now. So guess what needs to be done now to execute the SENDOUT command that's written into file P.MEX? If you said READ P, you're right on! Congratulations! If you didn't guess correctly, please review what we've done so far and also review the MEX documentation. And now we've only got two steps left to reach the top landing. Everybody aboard now? Alright, let's move on up. And here's where you might have just a wee bit more difficulty. MEX has a marvelous bit of its own duplicity that permits us to say one thing when we really mean another, kinda like some females I've known. Just look again at that one line SENDOUT command in the P.MEX file: SENDOUT "C DIALaaa//12,uuuuuuuu,pppppppp^Me" I'm going to surgically remove the 3-digit area code, "aaa", and in its place, let's put something else, like "{1}". This numeral, ENCLOSED WITHIN BRACES, is called a formal parameter. It may also be referred to as a variable symbol. Whatever you want to call it is OK with me. Just remember that IT MUST BE ENCLOSED WITHIN THOSE BRACES. Now, go back to your word processor and change the SENDOUT command, and then save it to filename P.MEX, like this: SENDOUT "C DIAL{1}//12,uuuuuuuu,pppppppp^Me" As you might have guessed, there's no free lunches around here. So the payment has to be made up at the READ command by appending the "aaa", where it's now referred to as an actual parameter. Whatever numbers we enter into the actual parameter will be substituted for the formal parameter when the READ command is executed. So our READ command will now look like this: READ P aaa [cr] instead of READ P [cr] The numerals used for variable symbols refer back to the actual parameters in the READ command, in sequential order. If you had a - + -7- mind to do so, you could replace the baud rate 12 with {2}, as an example. Then you would have to follow the aaa in the READ command with a 3 or a 12. (I personally always use 12, even for 300 baud transmission. It works, and a 1200 baud port seems easier to come by than a 300 baud port.) Whew! I'm all out of breath. So let's take a short breather, just long enough to make sure that everything so far is clearly under- stood. OK? Everyone still here? Ready now for the final push. The top landing is only a small step away. This last step takes us to the EXTEND stat switch variable. We're going to turn it on. And you ask me how come? And I say back to you because I say so, and also because I'm lazy, and if we turn on this switch, then MEX will let us forget to write the READ into the READ command line. How's that for doublespeak, huh? So try it, you'll like it! And so we now can use just: P aaa [cr] instead of READ P aaa [cr] It should be very clear to you readers at this point that MEX has allowed us to make up a phantom command, which will be executed by MEX like any other legitimate intrinsic MEX command. What's more, even if you still don't understand how it works, you don't have to. All you gotta do, dummy, is press a P and an Area Code number. OK? Now that's simple enough to satisfy the original groundrules! Moreover, none of the valuable 404 bytes in the MEX keystring file needs to be used for city access strings. You can use the entire file for all your other strings, like commands, names, telephone numbers, BBS passwords, or whatever else. So you see, we don't have to pay a penalty in that department anymore either. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 6.2 HERE'S THE FINAL DETAILS - NOW GO GETTUM, KEMOSABE! ----------------------------------------------------------- If you waded through all the preceding stuff, and understand any of it, you've earned the right to the final critical details and values. And even if none of it makes sense to you, just take your numbers and good riddance! I also once thought about saying "to be continued next month." But I don't want to be bothered with doing another paper any more than anyone out there really wants to bother reading one. So here's the goodies: Error character: @ (Critical value. Others may cause freeze.) Stat CANCEL: ^M (Critical value. Others may cause freeze.) Stat ERRID: Switch OFF (Not critical, but may save time.) Stat EXTEND: Switch ON (Needed for the phantom command.) Stat REPLY: 6 sec. (Timeout factor. Not critical.) Stat RETRY: 255 (Max retransmissions. User may change.) Stat TRIGGER: @ (Critical value. Telenet command prompt.) Stat WTECHO: Switch ON (Mandatory setting.) Abort the loop: CTRL-C (This can be done at any time) - + -8- 7. S O M E W O R D S O F W I S D O M ------------------------------------------ Here's just a few more finishing touches now, plus review of some of the lessons learned. There's some important new information in here too, regarding the actual operation of this PCPFAST method of accessing a PCP city, so please read it all very carefully to make sure that you have a clear understanding of what you must do. (1) Set up a READ file P.MEX, or whatever other name you want to use, and store it on disk. It should contain the one-line SENDOUT command and string described above, with the formal parameter {1} in place of the area code. Remember the braces! Also, don't forget to append the error character, "@", to the end of the string, immediately following the "^M". (2) Set up the principal stat variables, as shown just above. Make sure that there are no active PREFIX or SUFFIX strings. (3) Set up and load your PCP.PHN and PCP.KEY files into MEX for use with PCP. Enter all your phone numbers, strings, etc. Don't forget to execute COLD first to clear out other data. (4) CLONE this MEX config for exclusive use with PCP. And name it MEXP.COM, perhaps. Then, when you want to use MEX for calling PC Pursuit, just call up MEXP from CP/M, and you're all set. (5) After a connection has been established with a local Telenet node, use ESC-E to return to MEX command mode. Then key in P aaa [cr] to initiate the SENDOUT command in the READ file, for area code aaa. If all modem ports in the destination PCP city are occupied, you'll get a "BUSY" response, and MEX will retransmit an access request approximately every 5.6 seconds. You may abort at any time with a CTRL-C, or equivalent key. (6) When a "CONNECT" is received, you'll see it. Now do a CTRL-C to abort the READ file. You'll probably time out, and go into the command mode. Enter T [cr] to go into terminal mode, then follow up with one or two [cr] entries until you see the "@" network command prompt symbol. Now THIS IS IMPORTANT for you to understand, so PLEASE READ CAREFULLY: As a result of what was done to manipulate MEX, you ARE connected to the called city at this point, but can't send any commands to its modem because you're now in the network command mode, as indicated by the "@" prompt. You must be in the data transfer mode to send commands to that modem. To go to the data transfer mode, enter CONT [cr]. Then you may send commands to that modem in the normal manner. Hint: Put "CONT^M" into your PCP.KEY file. (CONT isn't a generally published Telenet command, so please make a note of it somewhere.) (7) It's probably a good idea to switch WTECHO OFF after you've established connection, but not essential. The ON state can possibly disrupt the normal operation of some keystrings. You can easily set up READ files for turning Stat WTECHO ON and OFF. They're much easier and faster to use than entering the full STAT commands. I use W.MEX and WF.MEX for filenames. If you do this, don't forget to turn WTECHO ON again before the next PC Pursuit call is initiated. - + -9- 8. T H E F I N A L W O R D ------------------------------ Good luck to everyone using this method of accessing PC Pursuit with MEX. It works just fine for me, and I see no reason why it shouldn't work just as well for anyone else. Hopefully, others will do some of their own experimentation, and perhaps come up with improvements, suggestions, etc. which may be beneficial to the entire CP/M - MEX user community. Constructive comments and feedback along such lines are sincerely requested. If anyone wants to reach me, I can be contacted as follows: By U.S. Mail: P.O. Box 1503, Havertown, PA 19083 By voice phone: (215) 878-9608 or 878-9609 By E-Mail: Drexel Hill Northstar RCP/M (215) 623-4040 Exclusive-80 (215) 739-9512 (Both BBS's are accessible via PC Pursuit) ----------- Larry Lavins Philadelphia, PA Jan 26, 1987 END OF FILE