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!RFOWLER@SIMTEL20.ARPA From: RFOWLER@SIMTEL20.ARPA (Ron Fowler) Newsgroups: net.micro.cpm Subject: [RFOWLER: Minor Mex112 bugs] Message-ID: <8855@brl-tgr.ARPA> Date: Sat, 2-Mar-85 01:48:15 EST Article-I.D.: brl-tgr.8855 Posted: Sat Mar 2 01:48:15 1985 Date-Received: Mon, 4-Mar-85 08:01:01 EST Sender: news@brl-tgr.ARPA Lines: 46 Date: Friday, 1 March 1985 23:39-MST From: Ron FowlerTo: Robert Bloom AMSTE-TOI 3775 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