<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Mon, 11 Jun 1984 12:08:00-PDT
From   : ABN.ISCAMS@Usc-Isid.ARPA
Subject: Re: File Transfers thru a TAC

Gerald,

I suspect you may be having the same problem I am with going through a TAC.
Downloads work fine, upload NO GO!  I suspected the TAC's input buffer was
to blame (heck, I can overrun that just by manual typing when the system
is slow), and someone else out on the net confirmed that.

They also said you can talk with your local TAC wizards about getting the
buffers expanded from their usual size (I THINK 60-some bytes) to 130-some
(whatever MODEM's packet length is) to overcome this problem.

I talked with mine, and they're talking with the Powers That Be, but no
big buffers yet (they're researching possible bad side effects).

I'm stuck too for packetized uploading, and so use KERMIT for all uploads
requiring error-checking.  (KERMIT's packet length can be adjusted, so
I routinely set them for 48 or so -- works fine.)  For other uploads
when the lines are clear, I engage flow control (FIS on my system) so the
TAC give me XON/XOFFs (so as not to overflow its buffers), and upload
right into a text editor -- works fine.  If I want a binary upload,
I use the PD utility UNLOAD to change my binary file back to hex (ASCII),
upload into the text editor, and send it that way for the other end to
LOAD or MLOAD (another PD utility) back to binary.

There's also a problem when uploading through a TAC -- the TAC's Intercept
Character.  I've patched both KERMIT and MDM730 to check each character sent
(in automated, bulk uploads) for the TAC Intercept Char, and if found, to
send it twice. This insures that character gets to the far end and the TAC
doesn't choke.  If you need more details on this, yell.

Hope this helps.

Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>