PCPMEX22 - A program to automate the use of PC-Pursuit with MEX+ for calling favorite haunts. Original Release: Sept 13, 1987 Current Version: 2.2 Written By: John Shotsky, Hillsboro, Or. Contact Information: Voice : (503) 640-9890 (1800-2300, Pacific Time) Cedar Mill Z-Node : (503) 644-4621 (24 Hrs) Messages BBS : (503) 648-1404 (Not active, can call voice) Address : 2233 NE Thomas St. Hillsboro, Or. 97124 Change History: V2.2 Added new commands, features, fixes. All new mnemonics in place and working. Extended area dialing supported. 10-29-88 V2.1 Added new commands, features, fixes. 5-25-88 J. Shotsky V2.0 Added new mnemonics for PCP. 1-7-88 J. Shotsky V1.0 Original Release 9/13/87 J. Shotsky Purpose: These scripts came into being through my laziness at trying to cope with the somewhat cumbersome manipulations required by PC-PURSUIT to access distant destinations. Some of the features: * Attach-detach local PCP * Attach-detach remote area code * Select new PCP area while attached to another * Select favorite remote phone destinations by menu * Unlimited retrys for any busy * Exit to DOS with or without disconnecting * Re-Enter MEX and resume operation from DOS * Automatic Password control * Uses new PC Pursuit mnemonics * Works entirely within MEX+. Not a separate dialer. What it does not do: It is not an automatic log-on system. Many systems do allow you to sign on and go right to some desired point with a single command. You will be able to autolog onto those systems. Other systems require a sequential sign-in, and for those, the program simply stores your password on key Q (Quick). The reason for not doing the autologons is simple: Sysops frequently interrupt or change their normal sequences, requiring additional or fewer 's to continue, or non-cancellable screens. If you want auto-logons, there are other scripts available to do them, those written by Rick Charnes, being about the best I've seen. His now require the use of Z-system, and make heavy use of a Real Time clock. NOTE: That's the way PCPMEX22 works...but I am considering adding a complete new script to handle auto-logon. It would work right along with these, transparently. Upon detection of a connect, another script would be called containing the logon sequences. That script may need editing fairly often (whenever a sysop changes the normal logon sequence), but them's the breaks. Eventually, we should have the auto-logon sequence for any BBS included in this list, but since that would make the logon script very large, (I've kept them all below 4K), additional similar scripts could be generated. The names could be PCPLOG1.MEX, PCPLOG2.MEX, etc. Then when connected, the proper script could be called by the program. Additionally, the logons for similar boards may be able to use subroutines, keeping the overall size of the scripts smaller. One thing to remember: The program always knows what you are connected to. Therefore, if you manually do some connecting or disconnecting without using PCPMEX, it will behave erratically. I've included a command for just toggling the status of the local node. If you're connected, it will go to disconnected mode, but it WILL NOT do a disconnect. If you just toggle it back you'll be where you were. I considered adding the same thing for the area, but, so far, haven't thought it out clearly to see if it could really be done with the current string variables. Something for the next version... Also, I've taken control of the modem with the scripts. I did that so the scripts could always know the modem status, could do a hang up and recall, if necessary, and so it PCPMEX would be able to more easily intercept modem responses and act accordingly. Now, if you disconnect your modem from the computer, PCPMEX will tell you that you did. If you disconnect the phone line from the modem, PCPMEX will tell you that, too! Helps you when you are having problems to know whether the modem or the phone line is at fault...A true Hayes 1200 Smartmodem is in use. The scripts can easily be modified to handle others. This all came about when I learned that some modems would respond in verbose mode and others would respond with numerical codes. There were just too many things to try to anticipate. Operation: Make the changes described below in the requirements section. Fire up MEX+. The PCP menu will appear. At this point, you have some choices: * Connect locally. * Select an area by number. (The program auto-connects locally.) * Do some other maintenance type thing. If you select an area, and the node is busy, it will ask you whether to retry. A is sufficient to tell it yes. Then it will ask how many times. Again, a is sufficient to tell it to try 25 times. Or you can tell it 1000, if you like. If you get tired of watching it retry, you can ^C out. When, (if), it connects, the screen will clear and another screen will present itself containing a selection of the BBS's accessible from that node. I've inserted a fairly good selection, but it's easy to add your own favorites. Some areas have no presets, (BBS screen will be blank) but you can still dial out to a phone number using menu selection 3. Note that there are some area codes listed for which there are no real mnemonics. The program knows which mnemonic to select, connects to the appropriate area, then tells you how to dial the extended area. If the BBS is busy, the same sequence of questions as above will allow you to retry until you either connect or give up. When the program connects to a BBS, you will be dropped into terminal mode online. Sign in normally, your first name is in 4, your last name is in 5, your first and last name is on 6, and your password is on . Do whatever...when you "BYE" off your destination, use , to return to PCPMEX. I tried putting an automatic recall of PCP on , but it was annoying to have the menu come up when you just wanted to escape to command mode. When you call PCPMEX back up, you can immediately select another area if you like, the program knows what to do. You can also , while still connected and then exit MEX connected. It takes a moment, because MEX clones another MEX named REMEX. Do what you like then restart MEX using REMEX. You will be precisely where you left off, and can exit to MEX terminal mode to get back on the remote system. (I don't know how long you can be off before PCP drops you!) I've observed Rick Charnes' method of saving status in ZCPR3, but feel that may be restrictive for those of you that don't run Z3. In fact, I will keep these scripts such that neither Z3 nor a RTC is required. Requirements: I run a 4 MHz KAYPRO II/IV/VIII, with a 58K system size, and ZCPR3.4. That leaves me with a 51K TPA. I have virtually no "out of memory" problems with either MEX+ or any other program. I have 4 800K drives. I keep MEX and all associated communication files on D:, (including FCRUNCH/UNCR, etc) and I do all my uploading and downloading on C:. The drive specifiers are hard coded into the scripts so I don't have to fool with them. Naturally, these drive specifiers must be changed in your scripts if you don't use them the same way. Modifications: INI.MEX: - Change to accomplish your requirements in addition to those needed by these scripts. I set up MEXPAT22 to establish the various buffer sizes and STAT variables. You may want different buffer sizes. If you use either the default sizes or make them larger, you may start getting memory problems. I decided to include MEXPAT22 in this library so others could see how mine is set up. I also wrote a terminal overlay for the Kaypro and set the line drawing characters all to solid blocks. That makes the screens really stand out with solid lines around things. I'm including that in the library, too so others can copy what I did. LOCAL.PHN - You will want to put your local phone numbers here. It's no longer used by the scripts, tho. LOCAL.KEY - You will want to put your key sequences here. Note how mine are set up. If you have trouble with a script doing something, you can usually go to terminal mode and do the same thing with the preset keys. The scripts keep the keys updated to the task at hand. Sooo, if you get a no-answer, and you don't believe it, just go to terminal mode (9), and press 9 to dial the last phone number manually. You will then see what is actually being sent back. Unfortunately, MEX+ can only intercept 4 responses, so if there are more than that, they fall into a catchall- unknown response...The same holds for an attempt to connect to an area: just go to terminal mode and use 7, 8 to re-attempt the last area the script tried to see what is going on if it doesn't connect properly. Note that I have keys set up for FIRST, LAST, and FIRST LAST. I use these when signing onto various boards. PCP.MEX - You may need to modify the modem hang-up in proc LDISC. You may also need to modify label XCONN to specify which drive REMEX is to exist on when generated. PCPAC.MEX - No Changes. PCPCH1 - No Changes PCPCH2 - This and PCPCH3, below, contain the actual phone numbers, passwords, and some logons for BBS's. You can delete those you don't use and add those, using the same format, that you need added. Be SURE to put your password (or system ID) everyplace you see PASS in these two scripts, or it may be wrong when you sign onto a BBS. Also, you'll need to update PCPSEL.MEX for each change in either of these. (See below) PCPCH3 - See above. This is just an extension of PCPCH2, to keep the size down. A PCPCH4 could be added if a lot more numbers are needed. All the Z-Nodes that are accessible by PCP are included. Many of the more popular BBS's are also included. PCPGET.MEX - This script actually connects you to PCP. You may need to change some of the modem control strings. In the CONNECT label, you may also have to change some terminal dependant items. PCPINIT - Change variable c to your LOCAL PCP node phone #. Change variable d to your USER ID. Change variable e to your PASSWORD. Change KEY Q to contain your PASSWORD. PCPMENU - No Changes. PCPPHN - No Changes. PCPSEL - These are the actual menu entries for the various BBS's. You will need to add and delete here for each add or delete in either PCPCH2, or PCPCH3. And that's it! These scripts operate properly only with MEX+ Ver 1.65, unless the next update (that I keep hearing about) contains the same idiosyncrasies. For example, in the INI.MEX section, the "STAT CASE ON" statement REALLY means STAT CASE OFF. Be sure to change it if you get a corrected release of MEX+. Also, some of the scripts appear to be longer or more difficult than one would expect. These are usually the result of work-arounds to resolve some problem. For example, you cannot use these statements: IF %A = %B @2,2 say 'They are equal' COMP %A %B And if you have too many single line IFs in a row, they will not work as expected. STAT Settings: STAT variables of interest that set these scripts up to work properly with PCP or are incidental to my hardware are as follows: EXTEND ON SILENT ON SODELAY OFF WTECHO OFF ID ON INITFILE ON FILTER OFF SMDISC ON QUEUE ON TRIGGER "" REPLY 0 RTIME 4 RETRY 6 ALERT 25 WECHO 2 CLOCK 40 WCHAR 60 SEARCH 2 WLINE 600 File List: INI.MEX - Initializes MEX LOCAL.KEY - 'Standard' key assignments (used by PCPMEX) LOCAL.PHN - No longer needed. GT.MEX - My new batch download script. Detects ZMD/KMD. MEXPAT22.Z80 - The patch file to set MEX up without using STAT and CLONE. MXT-KP10.Z80 - The Kaypro terminal overlay. PCP.MEX - Main program script PCPAC.MEX - Area Dialer PCPCH1 - Converts area menu selection to proper MNEMONIC PCPCH2 - Converts BBS menu selection to proper phone numbers+passwords PCPCH3 - Same PCPGET.MEX - Local PCP Node Dialer PCPINIT.MEX - Initializes PCPMEX PCPMENU.MEX - Menu for PCPMEX PCPMEX22.DOC - This file PCPPHN.MEX - Phone Number Dialer PCPUSE.INF - List of variable assignments Changes: These scripts are released to the public domain. I only request that you observe normal courtesy when changing these scripts, updating the change history, giving credit where due, and rolling the version numbers as necessary. Send updates to the Cedar Mill Z-Node. If you have requests to make, send those to the Cedar Mill Z-Node, or write me at the above address. My bulletin board will be up soon, and when it is you can access me here. In any case, GIMME SOME FEEDBACK!!! Wish List: MEX+ is a superb program, probably the best CP/M comm program around, and its dBASE-like script programming method was a brilliant idea. Like any good program, tho, it will see added features and bug solutions over the years. I have included this short "wish list" toward that end. I would find the following features useful in script programming: * The ability to "SKIP + OR -n" Lines, or Commands. * The ability to create a longer single line IF (a + at a break?) * Shouldn't be a limitation on the number of single line IFs in a row. * The ability to use comparison operators on 2 numeric variables at a time consistently. ( If %a>%b, etc) This works for some operations but not for others. * The ability to transfer between numeric and string variables. (binary to ascii to binary conversion), or the ability to do math on ASCII numbers. * More string variables (16 would be nice). Could be shorter (16 Char). Naturally, if string variables could be set to Keys, and then the keys could be manipulated with scripts (SENDOUT KEY 9) then more string variables WOULD be available. * A way to parse and/or concatenate strings, so you could build commands or sendout strings. You can sorta do that now (SENDOUT {A}), but that whole area could be better. * A way to embed a sting variable in another: ie., store "C D//{A}//PWD" to D. * More robust GLOBAL READ command. (GLOBAL READ "";STOP should work properly, for example. * Should be easier to go to either command or terminal mode from a script file. * The ability to exclude comments when loading a script. Now, all the comments are loaded along with the scripts and the script parser must determine if a comment is a command. It uses memory that is already precious. * More robust label reading. If labels are named "label1", followed by label "label", and you "goto label", it will sometimes "goto label1". If a space follows "goto label ", the space is significant too! (oops) * ZCPR3 compatibility. Not mandatory, but compatible. Possibly, two versions: one a full Z3 program and the other pure CP/M. * The ability to 'sendout' the contents of a KEY! This would greatly simplify script writing, especially if you could embed variables like {A} within the key description. * The ability to send commands to the OS. * A MAJOR change: A module or some such that makes MEX+ actually operate as a BBS. It might incorporate BYE and BBS stuff, or just call them up, but it IS a communications program, and, as such, would greatly simplify things if it could also act as a BBS controller. MEX+ already knows all about your system, clock (if you have one), terminal, modem, etc. All that is duplicated in BBS programs. If this isn't deemed a good use for MEX+, then some new script commands that would allow users to construct a BBS from scripts would be nice. * Built-in PC-Pursuit compatibility. Then all these scripts would be superflous. * Add ZMODEM protocol. * Allow cloning of MEX+ to eliminate un-needed protocols, thus shortening MEX+. One could then have different versions of MEX+ that operate with different protocols. As I write this, I have heard that the ownership of MEX+ may be passing to the ZCPR3 architects. It goes without saying that this is a very interesting occurance. Credits: I read all the MEX+ scripts I could find. Everyone who has written scripts gets some of the credit for this set, since many of the ideas came from those forerunners. Hopefully, I have contributed some more ideas upon which you can build. In particular, Rick Charnes has built up a set of similar scripts. His are mostly DOS command line driven, while mine are strictly menu driven. I am striving to provide the same basic features, so the user base may have the same features but choose the program style they prefer. We discussed a combination of our efforts, but it seems that they are simply not combinable. (Is that a word?) I got my clock going, so will be adding some time functions to the next version. Enjoy! John Shotsky