thad@cup.portal.com (Thad P Floryan) (01/02/91)
vjg@cbnews.att.com (vincent.j.guinto) in <1991Jan1.211151.19163@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@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]vjg@cbnews.att.com (vincent.j.guinto) (01/02/91)
vjg@cbnews.att.com (vincent.j.guinto) (ME!) in <1991Jan1.211151.19163@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. > > [...] > Thanks to a couple email responses I received last night, I was able to solve this problem and get umodem to work for me. The general concensus was that it was a flow control problem, due to something in the header of the 19th segment (or 18th, depending on the person responding) looking an awful lot like a <CTRL> S character. I turned of flow control on my 7300, and it still croaked. I then turned off flow control on the mainframe I was trying to send the files to, and it worked! Somebody mentioned that they had to buy a special phone line to get around this flow control problem. Fortunately I'm dialing into a fairly smart network (AT&T's Datakit, to plug one of my company's products), and I can turn flow control on/off at my whim once I'm connected. So, thank you all for your help and advice. Shutting off the flow control worked just fine, and the problem is solved! P.S. For those who recommended using kermit instead, I looked and looked and couldn't find kermit on the mainframe. Why, I don't know, but it just ain't there (rats!). Someone deemed my desire not to use HDB as "shortsighted." Can anyone clue me in on what benefits I'll see by using HDB? I don't receive any calls into my 7300, and don't normally poll for email or any of those other things you can do with uucp, mostly because I don't use the 7300 all that much anyway. I suspect that for a low-powered user like myself, something like HDB wouldn't pay off in a cost/benefit analysis. Any opinions? (now that's a silly question, I'd be surprised if there WEREN'T any opinions!) ---------------------------------------------------------- Vince Guinto att!cblph!vjg AT&T Bell Laboratories Opinions are mine, Columbus, OH not AT&T's