simon@ms.uky.edu (Simon Gales) (12/12/88)
I have never gotten the zmodem protocol working between Dsz and Rz/Sz, so I
never registered it, thinking it broken.
So, if I register it, does that enable zmodem transfers?
--
/--------------------------------------------------------------------------\
Simon Gales@University of Ky UUCP: {rutgers, uunet}!ukma!simon
Arpa: simon@ms.uky.edu
MaBell: 263-2285/257-3597 BitNet: simon@UKMA.BITNET bobmon@iuvax.cs.indiana.edu (RAMontante) (12/12/88)
simon@ms.uky.edu (Simon Gales) writes: > >So, if I register it, does that enable zmodem transfers? Nope, the unregistered DSZ I tried out does zmodem transfers in both directions. If you're connecting to your host via a network, that network's involvement may be preventing successful zmodem transfers. The "Sytek" coax cable that I.U. employs does this, possibly because it imposes XON/XOFF protocol on the connection whether the endpoints want it or not (or possibly for another reason :-). I have not been able to do any but 8th-bit-quoted-Kermit transfers over this irritating link, which is the major link to most of the University's computers. I can use zmodem on a C.S. Department (Ultrix (UN*X)) computer to which I can dial in directly. The dial-in requires that I use 7-bit-Even-parity (using Procomm, Zcomm, and any other emulator I've ever tried), but I think that DSZ ignores that. Zmodem protocol also works over rlogins to the other machines, once I've gotten that direct phone line. To do a download, I give the host the command "sz filename"; then I either call up Procomm's ymodem-batch download protocol, or invoke DSZ with the parameters "rz t" (I think the "t" parameter is correct). Either one takes it from there, although DSZ remains as a dumb terminal interface at the end, until I exit it with the F1 key, so I could start further "sz ..." host commands if I wish. "Helpful tip": It's been suggested that if you get stuck in a zmodem session, a long-enough string of ctrl-X's will eventually terminate without having to hang up or hope for a timeout. I recall being very frustrated about this point, before I got zmodem working for me. Hope this helps, as they say....
caf@omen.UUCP (Chuck Forsberg WA7KGX) (12/13/88)
In article <10689@s.ms.uky.edu> simon@ms.uky.edu (Simon Gales) writes:
:I have never gotten the zmodem protocol working between Dsz and Rz/Sz, so I
:never registered it, thinking it broken.
:
:So, if I register it, does that enable zmodem transfers?
DSZ does not have to be registeres to perform ZMODEM files transfers
with rz/sz. You should be able to use the DSZ "t" command to talk
to Unix, then say "sz foo.bar" to the shell to send a file from Unix
to you. If this doesn't work the sz program wasn't compiled correctly,
else you're using some sort of lobotomized data PBX that's messing
with the bits.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla BBS: 621-3746 CIS: 70007,2304 Genie: CAFRalf.Brown@B.GP.CS.CMU.EDU (12/13/88)
In article <15744@iuvax.cs.indiana.edu>, bobmon@iuvax.cs.indiana.edu (RAMontante) writes: }If you're connecting to your host via a network, that network's }involvement may be preventing successful zmodem transfers. The "Sytek" }coax cable that I.U. employs does this, possibly because it imposes }XON/XOFF protocol on the connection whether the endpoints want it or not No, XON/XOFF doesn't bother Zmodem, since it never sends those characters in the data packets (it does send an XON at the beginning to make sure things aren't stopped). It can also handle the connection swallowing any control character but ^X with the -e option. What Zmodem absolutely can't handle is a seven-bit connection or one that swallows ^X. The protocol document from Omen Technologies does indicate that seven-bit transfers may be implemented in the future (there's a flag bit in the pre-transfer negotiations). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
pjh@mccc.UUCP (Pete Holsberg) (12/16/88)
In article <728@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
=DSZ does not have to be registeres to perform ZMODEM files transfers
=with rz/sz. You should be able to use the DSZ "t" command to talk
=to Unix, then say "sz foo.bar" to the shell to send a file from Unix
=to you. If this doesn't work the sz program wasn't compiled correctly,
=else you're using some sort of lobotomized data PBX that's messing
=with the bits.
I tried "DSZ t" from C:\>, expecting to get terminal mode. Instead, it
said "carrier lost" and then returned to C:\>.
???
Pete
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/16/88)
In article <491@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >I tried "DSZ t" from C:\>, expecting to get terminal mode. Instead, it >said "carrier lost" and then returned to C:\>. Well, did you ever find that carrier?? I avoid losing it by using a batch file to supply the "d" parameter to dsz. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
thaler@speedy.cs.wisc.edu (Maurice Thaler) (12/17/88)
You need to use
dsz CON port n speed nnnn d t
the d means don't carrier detect
Maurice Thaler SYSOP Audio Projects BBS (608) 836-9473
SYSOP Power Board BBS (608) 222-8842