rbloom@apg-1.ARPA (Robert Bloom AMSTE-TOI 3775) (03/01/85)
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 <esc>-'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 bloomRFOWLER@SIMTEL20.ARPA (Ron Fowler) (03/02/85)
Date: Friday, 1 March 1985 23:39-MST From: Ron Fowler <RFOWLER> To: Robert Bloom AMSTE-TOI 3775 <rbloom at apg-1> cc: rfowler at SIMTEL20 Re: Minor Mex112 bugs I believe I have the lost character problem tracked: do you have an abnormally large TPA? If STAT BUFFER shows a buffer size >32K, then then MEX gets mixed up. It seems to be caused by one of the disk write sector counters being limited to 8 bits. This only shows up in the larges of systems. An interim fix (until I can get out from under my current workload and issue an update): use MEXPATCH to create a *real big* phone directory (increase it until STAT buffer drops below 32K). The '/' problem with keystrings is an algorthm error in the keystring readback routine; it needs re-writing, and will get it in the next rev. In the meantime, I believe that temporarily redefining the keystring with two '/' characters -- which requires that you type four, actually -- just prior to saving the .KEY file will work. I This, of course, is a *real* pain if you have a lot of keystrings with slashes in them. The only download error that doesn't draw a diagnostic is the out-of-sync problem: typically, a NAK from the receiver gets permuted into an ACK; the sender begins sending the succeeding record, MEX has missed the record it NAKKED, and there is no provision in the protocol to back up. MEX knows it can't recover from this, and simply branches to the ABORT routine. Next time I'll make it print "fatal sync error" or somesuch. Note that the latter problem occurs most commonly when transfers are taking place through a network (or interrupt driven sender). GZ @MC explained why this is so a couple of years ago, but the details of her explanation escape me right now. I hope to roll a better protocol for MEX 2+<.something>, based on extensions of the old ... Thanks for reporting the problems so thoroughly! Often, I get things like "SENDOUT doesn't work right", with not clue as to what exactly doesn't work (in case you're wondering, the problem with SENDOUT occurs in overlays that loop on status-false in the input-modem-port routine; this routine should either return 0 if it can't read the modem port for some reason, or perferably, return the last character seen). --Ron