Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!rbloom@apg-1.ARPA From: rbloom@apg-1.ARPA (Robert Bloom AMSTE-TOI 3775) Newsgroups: net.micro.cpm Subject: Minor Mex112 bugs Message-ID: <8818@brl-tgr.ARPA> Date: Fri, 1-Mar-85 11:18:29 EST Article-I.D.: brl-tgr.8818 Posted: Fri Mar 1 11:18:29 1985 Date-Received: Mon, 4-Mar-85 06:16:27 EST Sender: news@brl-tgr.ARPA Lines: 52 Minor bug reports in MEX112: 1. MEX v112 lost an ASCII capture file and did not save the whole file correctly when I exited with a 'CPM'. This is what I did and what happened: Opened ASCII capture file 'TRNSCRPT' Recorded ~5k characters Stopped record with-'U'nsave Did a couple MODEM2 file tranfers Logged out of remote and exited MEX with 'CPM' I did get the message 'saving TRNSCRPT' upon leaving MEX, but the file contained only ~200 characters. I've had the problem before and usually solve it by 'WRT' the transcript before exiting. (Forgot to do it this time however.) I don't know if the MODEM2 tranfer had anything to do with it. 2. A second incident came about when I was attempting the transfer a whole batch of keystrings from one version of MEX to another. Easy, I thought, just save FILE.KEY from one and load FILE.KEY from the other. However, I kept getting a 'syntax error' on the load command. I tracked it down to the '/' character in one of the keystrings. (The use of the back slash '/' character is documented in the manual but not in the on-line help file, or at least not under LOAD/SAVE or STRINGS.) If the keystring has a single back slash as in 'KEY A="cd usr/anywhere/anywhat^M" the SAVE command saves it with single backslash. But when the LOAD command reads the key file it expects to see double back slashes. Therefore, I suggest the SAVE command save the file in a form that the LOAD command could read it. 3. (Not really a bug but annoying) Occasionally during MODEM2 file transfers MEX will end the transfer with a "File Transfer Aborted" without any mention of NAK's, retries, or other errors. It usually only occurs which downloading long, >50k transfers (naturally!), and with otherwise clean lines (very few NAK's). It has not occured during uploads. The remote host goes on sending blocks after MEX has aborted until the remote computer (I use umodem on the remote unix machine) times out. It is almost as if the local user had typed an ^C to abort the transfer. Has this been reported before or is it maybe hardware related? I've not had this problem with MDM7 when I used it. I am using the MXO-NS11 overlay for the second serial port on my NorthStar Horizon. Otherwise, MEX is fine. I much prefer it over MDM7 as the command interface is closer to how I naturally think. And the read command is great! - as umodem doesn't allow batch transfers, I ended up using a read file for a psuedo batch transfer of all the zcpr3.com files. 50-some files in 60 minutes! I couldn't possibly type the command lines fast enough to do that, even if I have enough concentration to jump on the prompts as soon as they appeared. -bob bloom