Date   : Fri, 01 Mar 1985 23:44:00 MST (Fri)
From   : Ron Fowler <RFOWLER@SIMTEL20.ARPA>
Subject: [RFOWLER: Minor Mex112 bugs]

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