🚀 go-pugleaf

In article <20477@agate.BERKELEY.EDU> lauac@wheeler.qal.berkeley.edu (Alexander Lau) writes:
> I really put Zterm 0.7 to the test this afternoon, and it failed.
> My setup is as follows: (Mac side) Mac SE, 1 Meg, System 6.0.2, various
> inits (MacroMaker, Suitcase II, MenuClock 101, Quote Init) that I've
> never had problems with.  (UNIX side) Sun 3/50, remotely logged in.  OS:
> Sun UNIX 4.2 Release 3.5.  Using Chuck Forsberg's (rz/rb/rx/sz/sb/sx)
> ZModem protocol for UNIX, compiled to run under BSD 4.2.  Here are the
> problems that I've noticed:
> 
> 1) Does not upload properly, using all conceivable configurations:
> rz/"Send ZModem", rb/"Send Ymodem 1K", rx/"Send Xmodem 128", and a few
> others.  I am using an 8-bit connection, as suggested by Dave Platt.
> 
> (Note: I tried the same tests with Microphone 1.1 (except for the
> ZModem test) and the results were the same.)
> 
> Upload tests with XMODEM 3.6 in lieu of rz/rb/rx also failed with both
> ZTerm 0.7 and Microphone 1.1.

This strongly suggests that your Unix box is not successfully switching
your input port over to 8-bit-raw-input when the upload begins, and is
being seriously confused by the binary data that's part of these uploads.

Remote login to SunOS is a bit tricky.  If you're dialing into one Sun
machine and then using "rlogin" to access your workstation, you *must*
use the "-8" option on the "rlogin" command; if you don't, then rlogin
will transmit only 7 bits to your workstation, and 8-bit file transfers
such as XMODEM uploads will become badly ykrwdvlppp.

If you're accessing your workstation via a TELNET-style remote login
(via an EtherNet TCP-based terminal concentrator, for example) you must
perform whatever incantations are necessary to ensure a transparent
8-bit data path all the way from your initial dialin point to your
workstation.

> 2) Does not download properly using ZModem file transfer protocol.
> This is more or less the reason the program exists!  sz from UNIX to
> ZTerm sends about 95% of the file, then hangs indefinitely.  If I
> cancel the send and resume it using the "crash-save" feature, the
> resulting Macbinary file is garbled and unusable (unless it is a
> Stuffit archive, in which case Stuffit tells me that the file is
> damaged and may not work properly.  I was able to extract all files,
> though.)  This phenomenon only happens with files over a certain
> size; I haven't been able to pin won the exact size, but it seems to
> download files of less that 8K without much trouble.

I had the same problem initially... it seemed to kick in whenever the
Mac actually wrote downloaded data to the disk.  My suspicion is that
ZTerm isn't issuing FlushVol() calls during the download;  thus, the
data that it writes is being stored in the RAM cache, and is being
flushed to disk only when the cache fills up.  I have a sneaking feeling
that ZTerm is losing data from its serial-port buffer during long disk
I/Os.

The fix to this is easy... use the undocumented "-w" option to "sz".
This puts the ZMODEM protocol into a sliding-window mode.  If you chant
"sz -w 2000 foo", then sz will send 500-byte packets, and will request
acknowledgement after each one.  It will NOT stop sending data unless it
has sent four packets and hasn't heard the acknowledgement to the first
one (i.e., the 2000-byte window has filled up).  ZTerm will normally
have no trouble ACKing frequently enough to keep sz happy;  the transmit
pipe will remain full and the line utilization will sit up at about 95%.
If ZTerm gets bogged down due to disk I/O, foreground application
activity, etc. and doesn't send all of its ACKs in time, sz will stop
and wait for the ACKs to arrive.

Since I discovered the "-w" option, I have had _no_ trouble downloading
massive files from my Sun 3/60 workstation, via an "rlogin wsn -8" from
the dialin port on our Sun 3/280, which is connected at 4800 baud to a
2400-baud MNP modem that I dial from another 2400-baud MNP modem to
which my Mac is connected at 9600 baud.

Quite simply... if it's possible for speed or protocol mismatches to
foul up a ZMODEM upload or download, then my particular configuration
has just about EVERY opportunity possible for such mismatches to creep
in.  I think I've managed to whip 'em all, though!
-- 
Dave Platt    FIDONET:  Dave Platt on 1:204/444        VOICE: (415) 493-8805
  UUCP: ...!{ames,sun,uunet}!coherent!dplatt     DOMAIN: dplatt@coherent.com
  INTERNET:   coherent!dplatt@ames.arpa,    ...@sun.com,    ...@uunet.uu.net 
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303