Re: Upload Madness!

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <3h4bug$1op@acme.freenet.columbus.oh.us>,
Dave Althoff <dalloff@freenet.columbus.oh.us> wrote:
> 
> It's been a frustrating night here at Coaster Central!
> 
> I have five term programs for my Apple, and I am presently trying to
> decide which one(s) to pay the SW fee on...
> o Telcom
> o Snowterm
> o Zlink
> o Kermit-65
> o ProTerm 1.1

TelcomGS and Kermit-65 are freeware.  ProTerm is commercial.  I think
the author of Snowterm vanished from the Apple II world a long time ago
(but the program is still shareware).  Z-Link is definitely shareware,
but hasn't been updated since 1991.

> Okay, PT1.1 is out because it isn't SW, and won't do VT-100.

Why not buy 3.1 then?

> Using the others, I tried to do an XMODEM upload to a local server.  Just
> a plain text file, sent in binary mode to avoid that blasted UNIX
> line-turn problem.  In all cases...ProTerm 1.1, Zlink, and Telcom...the
> upload got about half-way through, then the UNIX host conked out. 

Sounds like a problem at the UNIX end if you ask me.  Does it conk out
at the same place each time?  How many blocks (or bytes) had been sent
and acknowledged up to that point?

If it was conking out on block 17 or 19 (around 2176 or 2432 bytes for
XModem-128, 17408 or 19456 bytes for XModem-1k), then it is probably a
problem with your UNIX host eating and/or pausing on Ctrl-Q and Ctrl-S
characters.

This is almost certainly due to a configuration error on the UNIX
host, but I don't know how to fix it.  An XMODEM program should run
with the terminal connection in "raw" mode, so that control characters
are not processed.  It is possible that the connection runs through a
terminal server or modem which is interfering with these characters (or
some other control characters).

Kermit doesn't use dangerous control characters (or characters with bit
7 set), so it works much more often (at the cost of a slower transfer).

> Finally, I decided that I had run into a problem with the host.  So I
> decided to use Kermit-65.  Only trouble is that the document came from
> AppleWorks, and Kermit-65 only seems to work under DOS 3.3 (it's supposed
> to work under ProDOS, but I have had no luck with it that way).

I haven't used Kermit-65 very much, so probably can't help there.  It
seemed to work fine under ProDOS for the limited time I used it.  (I
don't have access to a host that uses the Kermit protocol, which makes
its use a little pointless.)

Which version were you using?

> So then I ran into the limitations of the DOS 3.3 FST under GS/OS
> System 6.0! 
> 
> Doggone it, why didn't those jerks who wrote GS/OS think that we would
> have any desire to take the translation the other way?  Arghs!

Or to Pascal, for that matter.  They are intended as migration tools,
not general FSTs.

Allowing writing to a DOS 3.3 disk from GS/OS would open up several
cans of worms.  What to do about a file with a resource fork, for
example.  DOS 3.3 is missing most of the directory fields expected by
GS/OS (no preservation of times) and has no way of storing arbitrary
file types.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand