home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!faatcrl!jprad
- From: jprad@faatcrl.UUCP (Jack Radigan)
- Newsgroups: comp.sys.amiga.datacomm
- Subject: Re: 'SZ'
- Message-ID: <3374@faatcrl.UUCP>
- Date: 22 Jul 92 04:12:42 GMT
- References: <Br5yDy.K2n@news.cso.uiuc.edu> <5377@ucru2.ucr.edu> <clemon.08fm@lemsys.UUCP>
- Organization: FAA Technical Center, Atlantic City NJ
- Lines: 22
-
- clemon@lemsys.UUCP (Craig Lemon VE3XCL) writes:
-
- > Check to make sure that you have a genuine 8 bit word length
- >connection. Ignore what the Jr-Comm status line says. In my experience,
- >JR will automatically switch from 8N1 to 7E1 without informing the
- >operator. This caused many an unsucessful zmodem download until I called
- >with another terminal that didn't exhibit this phenomenon and found out
- >that the UNIX machine wasn't set for 8N1 after all. You may be forced to
- >use 'sb' for YModem-Batch which worked fine for me. The above is just
- >something to try because it happened to me. Your actual problem might be
- >something totally different.
-
- The switch to 8n1 is automatic and required when you initiated a file
- transfer as all of the protocols *need* an 8 bit connection in order to
- work. The status line is not changed however as the device will be reset
- back to the settings in use when the connection was first established.
-
- But, as you point out, JR-Comm changing to 8n1 is not enough, the entire
- connection must be 8 bit transparent in order for the file transfer to work.
- Since the UNIX box was not set to 8n1 the transfer failed.
-
- -jack-
-