Date   : Sat, 14 Jan 1984 00:55:01 EST
From   : Keith Petersen <w8sdz@brl>
Subject: Hoff notes on MDM717 update

Forwarded message from Irv Hoff to Dave Hardy and myself...

---
01/12/84
Hi Dave / Keith

Here is MDM717 as promised.  Took longer than I had planned.  Paul
Grupp was telling me about a problem with the "V" flag.  Took me
most of the day to track that down as it was actual a dual problem.
(1) stack problem in the MOmin area and (2) a DATAFLG problem in
the RCVCHR area that took quite awhile to track down.  That one
caused the results with "V" to be similar to those with "R" and
showed the non-ASCII characters as (0D) hex characters when it
wasn't supposed to.  The stack problem of course just bombed things.

Dave Mabry also pointed out a problem with the LOGON message being
inconsistent at times.  (I had noticed that also but rarely use it and
did not get around to tracking down the problem until yesterday.  I
am pretty sure that is solved now, I can't get it to act up any more
on several different systems, and don't see how it can, now.

The main thing I got into MDM717 for was to fix a problem the fellows
are having on Compuserve with "save to disk".  Since many do not have
BUFEXC or CSEXEC, they just download ASCII files directly to disk (and
take their changes on no errors).  But MDM716 was saving to disk every
2k (instead of every 16k like I had it set for, Plouffe changed that,
it's now back to 16k with a note to leave it that way for distribution
copies and if an individual user wants to change it later, fine.)  When
set for 2k the problem during transfer to disk was aggravated badly.

I was stripping off parity from incoming characters but failed to also
do that during the time we picked up propagation delayed characters re-
ceived after an X-off.   It was very simple to fix with an ANI 7FH in
the INMODEM area.  Then started finding things that needed to be done
with MDM716.

Now I did not change anything Plouffe did, basically.  I was going to,
then decided against it.  All I really did was add an option to use
what he has now for GETACK, or with ACKNAK set to "normal ('YES') for
RCPM, it resends the sector immediately on any non-ACK.  Since XMODEM
will time out with 10 errors, we do not ask if you want to "try again"
after you get 10 errors - knowing that XMODEM has already terminated
the file transfer at the RCPM end.   But with ACKNAK set for ARPANET
to "NO", you only resend a file with a valid NAK.  This can take up to
about 1-1/2 minutes the way Plouffe re-did the GETACK area, for each
error.  After 10 errors, it THEN asks you if you want to continue.

So think we have the best of both worlds, now, and Plouffe should be
happy, and I guess I am too.  It's all automatic, with how you set the
equate at ACKNAK.

That about takes care of things.  With any luck, this version will last
3-4 days before Sigi Kluger or somebody decides to take yet another
crack at it.

It is possibly my last effort at MDM7-anything.  My next "big deal" is
going to be called either "MU-1" or "MC-1" or "MCU-1" have not made up
my mind yet.  Will support RCPM and CIS protocols, and include BUFEXC
as part of the program.  Will be a little more along the lines of YAM,
perhaps.  Only assembly level source.

This is already on several west coast systems now.  These systems are
so private the three big ones in this area are talking about going re-
stricted on users.  Maybe something along the lines of what Gary
Shaffstall is doing in Denver or even Jud Newell.  Hate to see that, but
it is getting impossible to get on some of these at all, without calling
on the voice line and making a schedule.  Auto-dial would be nice, but
one hates to work that hard to give programs away!

                               Best regards,      Irv