UMODEM problem

[Thad P Floryan]

vjg at cbnews.att.com (vincent.j.guinto) in <1991Jan1.211151.19163 at cbnews.att.com>
writes:

	I use umodem to transfer files between computers at work and
	my 7300 (OS version 3.5) at home, at 1200 baud. I've also used
	it at 9600 baud.

	The transfer works just fine from the mainframe to the 7300,
	but when transferring backwards from the 7300 to the mainframe,
	the transfer always fails at the 18th segment (or block, or 
	whatever term umodem uses to divide up a file).

	This failure has occurred at both 1200 baud over a phone line
	and at 9600 baud via a serial port, and occurred on two different
	mainframes, which makes me inclined to believe that the problem
	is on the 7300. I've used both text and binary transfer modes.

	[...]

The KEY here is that the failure is really occurring ON the 19th "frame".
If you look at an ASCII character table chart, you'll note that character
number 19 is a control-S (aka ^S aka X-OFF).  What's happening during an
XMODEM (aka "umodem") file transfer is that the data link is being told to
stop ... ^S means X-OFF which means stop sending.

I have the same problem in/out of my "mainframes" at my office when going
over either our braindamaged DCA network or our Robin/Metapath network.

Your ONLY solution is a direct line in/out of the mainframe to/from the 3B1.

My solution was to contract with PacBell for a special phone line which I
use to bypass all my company's networks ... works fine now to/from our VAX,
DEC-20, and other systems.

The problem is NOT specific to the 7300 ... it will happen with ANYTHING.

>From a technical point of view, it's crazy for software flow control to be
"in band", which is why high-speed lines use "Hardware Flow Control" over
the RTS/CTS lines (only really possible with a hardline or certain modems).

Thad Floryan [ thad at cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]