lauac@wheeler.qal.berkeley.edu (Alexander Lau) (02/17/89)
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.
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 know Dave Alverson said the crash-save feature did not work properly
with Macbinary transfers, but without it, I would be wasting mucho
tiempo on unfruitful file transfers.
The file transfers were successful, by the way, with YModem and with
XModem, and YModem was actually faster than ZModem (no false error
retries, and no indefinite hangs). This, perhaps, is due to the
complexity of the ZModem protocol and the incompleteness of the ZModem
implementation, but I can't be sure of that.
Disclaimer: I am otherwise a fairly happy user of ZTerm 0.7, and I will
be more than glad to send in my $30 once these bugs are fixed.
--- Alex
{att,backbones}!ucbvax!qal.berkeley.edu!lauac
OR lauac@qal.berkeley.edu@ucbvax.berkeley.edulauac@wheeler.qal.berkeley.edu (Alexander Lau) (02/17/89)
As a postscript (tm) to my previously posted article on ZTerm
downloads failing, let me add that using the windowing option
(sz -w 1024 filename _or_ sz -w 2048 filename) does increase
the chances for a successful download on a large file. This was
suggested to me by Dave Platt, and I had forgotten to include it
in my tests.
Another postscript (tm): The vt100 emulation is only half a step
above Microphone 1.1 (which has, as you all know, horrible vt100
emulation). Just in editing this article in vi, the emulator
made a spectacular show of adding text in the middle of a line.
Yet another postscript (tm): ZTerm 0.7 seems to lose the "Date
Created" and "Date Last Modified" of each MacBinary transfer it
does. If, however, I transfer the file as BinHex'd text and then
UnBinHex it with Stuffit after the transfer, the real information
comes out; therefore, it is there and ZTerm is throwing it away.
(Note: Microphone 1.1 does this as well.)
--- Alex
{att,backbones}!ucbvax!qal.berkeley.edu!lauac
OR lauac@qal.berkeley.edu@ucbvax.berkeley.edudplatt@coherent.com (Dave Platt) (02/17/89)
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
leonardr@uxe.cso.uiuc.edu (02/18/89)
lauac@wheeler.qal.berkeley.edu(Alex Lauac) writes in comp.sys.mac > >Another postscript (tm): The vt100 emulation is only half a step >above Microphone 1.1 (which has, as you all know, horrible vt100 >emulation). Just in editing this article in vi, the emulator >made a spectacular show of adding text in the middle of a line. > We realized that the VT100 emulation in version 1.1 of MicroPhone was quite inadequite, which is why both MicroPhone II and MicroPhone 1.5 both do a quite solid VT102 emulation which has no problem with either vi or emacs. Version 1.5 is available for $15 from Software Ventures Corp for those who wish to upgrade. The other differences between 1.1 and 1.5 include better support for currently hardware/system software, bug fixes, better printer output and FULL MULTIFINDER COMPATIBILITY (both scripting and transfers)! >Yet another postscript (tm): ZTerm 0.7 seems to lose the "Date >Created" and "Date Last Modified" of each MacBinary transfer it >does. If, however, I transfer the file as BinHex'd text and then >UnBinHex it with Stuffit after the transfer, the real information >comes out; therefore, it is there and ZTerm is throwing it away. > >(Note: Microphone 1.1 does this as well.) > To our knowledge, this is not the case. All versions of MicroPhone (since 1.0) have adhered the MacBinary (both MBI and MBII) standards and as such should have set the Creation and Mod dates ASSUMING that the uploading application properly set those fields of the MacBinary ehader. +---------------------------------+-----------------------------------+ + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + AppleLink: D0025 + +---------------------------------+-----------------------------------+