zmodem with cu, kermit
Chuck Forsberg WA7KGX
>I've been using zmodem for transfers between my ISP (a Unix system) and
>Telix for some time. This works great; if I say "sz" on Unix, Telix
>wakes up and handles it. If I say "rz", I can tell Telix to start the
>upload. No probs.
>
>But now I want to be able to transfer from Unix to Unix -- i.e. without
>whizzy comm software that triggers on the zmodem sequences. How do I do this?
>
>I tried using "cu" as the communications program, and tried all the various
>cu magic commands that seemed to make sense. I.e. I would run "sz file" on
>the remote system, and enter "~&rz" or "~|rz" on the local system. No go.
>So then I tried Kermit -- basically running "sz file" on the remote, then
>escaping to Kermit and running "!rz". But the Kermit process apparently still
>had ahold of the comm line, and the sz/rz never connected with each other.
>
>What's the right way to do this? I would prefer cu over Kermit, but either
>is acceptable.
You need a program designed to support ZMODEM in a dial-OUT enviornment.
--
Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406 FAX:-3735
Omen Technology Inc "The High Reliability Software"
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, GSZ and DSZ
TeleGodzilla BBS: 503-621-3746 FTP: ftp.cs.pdx.edu pub/zmodem
steve scrivano
>In article <3hqpg7$c...@tadpole.fc.hp.com> fr...@sde.hp.com writes:
>>I've been using zmodem for transfers between my ISP (a Unix system) and
>>Telix for some time. This works great; if I say "sz" on Unix, Telix
>>wakes up and handles it. If I say "rz", I can tell Telix to start the
>>upload. No probs.
>>
>>But now I want to be able to transfer from Unix to Unix -- i.e. without
>>whizzy comm software that triggers on the zmodem sequences. How do I do this?
>>
>>I tried using "cu" as the communications program, and tried all the various
>>cu magic commands that seemed to make sense. I.e. I would run "sz file" on
>>the remote system, and enter "~&rz" or "~|rz" on the local system. No go.
>>So then I tried Kermit -- basically running "sz file" on the remote, then
>>escaping to Kermit and running "!rz". But the Kermit process apparently still
>>had ahold of the comm line, and the sz/rz never connected with each other.
>>
>>What's the right way to do this? I would prefer cu over Kermit, but either
>>is acceptable.
>
>You need a program designed to support ZMODEM in a dial-OUT enviornment.
>
>--
Just run this script when you escape from kermit. Notice how input/output
redirects rz/sz to the /dev ports.
echo "
This utility runs rz/sz when you are using another
communication program such as kermit, etc. To use this
utility, run your communication program like you normally do,
escape back to your communication prompt, and shell
escape with > ! zscript"
echo
echo -n " > (S)end or (R)eceive Zmodem? "
read reply
case $reply in
s | S) echo -n " > Enter filename to send "
read name
echo -n " > Enter modem port (example: tty01) "
read tty
sz -b -w 2048 $name </dev/$tty > /dev/$tty
echo " "
;;
r | R) echo -n " > Enter modem port (example: tty01) "
read tty
rz -b </dev/$tty > /dev/$tty
echo " "
;;
esac
--
Steve Scrivano
sscr...@nyx.cs.du.edu
Gary Fritz
: You need a program designed to support ZMODEM in a dial-OUT enviornment.
Well, I figured out that the REDIRECT command in Kermit works fine.
I still haven't found any way to use cu, but at least I'm in business now...
Gary
Gary Fritz
: May I ask why not just run C Kermit? It's fast,
When I finally figured out how to invoke sz/rz from C Kermit, I got
transfer rates of 1800-1900 cps. Then I transferred the SAME file,
on the SAME link, SAME session, with Kermit -- and got 135 cps.
Obviously Kermit can do better. I'm just sick&tired of futzing with
all its configurations, knobs, levers, buttons, twiddles, and other cruft.
sz/rz ran fine "out of the box," and it supports many of the other features
you list for Kermit.
Gary
Christian Weisgerber
> You need a program designed to support ZMODEM in a dial-OUT enviornment.
Like the old rz/sz's still floating around.
When I have to use ZModem, I do it from the C-Kermit 5A(190) prompt:
redirect lrz
or
redirect lsz foo.bar
lrz/lsz ('l' like Linux) are cosmetically modified versions of old
versions of Chuck's rz/sz programs, versions that were still in the
public domain then and not crippled to prevent use in dial-out
environments. They're probably lousy, but not more so than, say, Telix'
built-in ZModem. :->
Unfortunately, I can't find any mention in the lrzsz docs on what
specific rzsz version they're based. You might want to look for lrzsz
and check it out. I guess, it's not particularly Linux-ified.
--
Christian 'naddy' Weisgerber, Germany na...@mips.pfalz.de
RNInet e.V. -- IP fuer Rhein-Neckar und Vorderpfalz.
Earl H. Kinmonth
zmodem is fine when you've got a reliable 8 bit path. when you don't,
it is nearly hopeless. that's where kermit shines. with kermit you
could probably transfer data between two tin cans connected by wet
string.
clean eight bit paths can be hard to come by when you're working over
x25 networks and through PADs.
the msdos versions of kermit also offer excellent terminal emulation
and code conversion for languages such as Japanese, Hebrew, etc.
--
Earl H. Kinmonth, Centre for Japanese Studies, University of Sheffield,
Sheffield, England S10 2TN jp...@sunc.sheffield.ac.uk
Chuck Forsberg WA7KGX
>Gary Fritz (fr...@sde.hp.com) wrote:
>: Joe Doupnik (j...@cc.usu.edu) wrote:
>: : May I ask why not just run C Kermit? It's fast,
>
>: When I finally figured out how to invoke sz/rz from C Kermit, I got
>: transfer rates of 1800-1900 cps. Then I transferred the SAME file,
>: on the SAME link, SAME session, with Kermit -- and got 135 cps.
>
>: Obviously Kermit can do better. I'm just sick&tired of futzing with
>: all its configurations, knobs, levers, buttons, twiddles, and other cruft.
>: sz/rz ran fine "out of the box," and it supports many of the other features
>: you list for Kermit.
>
>zmodem is fine when you've got a reliable 8 bit path. when you don't,
>it is nearly hopeless. that's where kermit shines. with kermit you
>could probably transfer data between two tin cans connected by wet
>string.
Kermit fans must only be interested in sending text files,
otherwise they's notice that Kermit throughput drops way down
when sending compressed files over 7 bit networks that eat
control characters. But what would one expect for a protocol
whose flagship programs generally default to destroying
compressed files?
It's a bit disingenuous to claim that Kermit sends files nearly as
fast as ZMODEM and also works over 7-bit links without mentioning
Kermit can't do both at the same time.
Gary Fritz
: : When I finally figured out how to invoke sz/rz from C Kermit, I got
: : transfer rates of 1800-1900 cps. Then I transferred the SAME file,
: : on the SAME link, SAME session, with Kermit -- and got 135 cps.
: with kermit you could probably transfer data between two tin cans
: connected by wet string.
Would it still transmit at 135cps? :-)
: the msdos versions of kermit also offer excellent terminal emulation
: and code conversion for languages such as Japanese, Hebrew, etc.
Wonderful. I'm sure that's a great feature for a lot of people.
But when all I'm trying to do is transfer files, and Kermit fails
miserably at that (in spite of configuration suggestions from several
experienced users), it's not worth my time to keep poking at it.
Gary
Kurt Klingbeil
Have you been able to make redirect rz/sz work on a kermit telnet connection ?
kk
Nico Garcia
Kermit fans must only be interested in sending text files,
otherwise they's notice that Kermit throughput drops way down
when sending compressed files over 7 bit networks that eat
control characters. But what would one expect for a protocol
whose flagship programs generally default to destroying
compressed files?
This is not fair. Kermit is a complete terminal emulation and
communications package, free and thoroughly tested on an incredible
variety of platforms. On my Sparc's at work I regularly get 1200 cps,
and only about a few percent more for zmodem when downloading to or
from MIT. And the kermit is much more robust on bad lines. So set it
to binary transfer and *leave it that way*.
It's a bit disingenuous to claim that Kermit sends files nearly as
fast as ZMODEM and also works over 7-bit links without mentioning
Kermit can't do both at the same time.
What? Yes it does. I do so regularly.
Nico Garcia
ra...@mit.edu
My opinions are my own, not MIT's or my employer's or my cat's
(Well, maybe my cat's....)
Frank da Cruz
Gary Fritz <fr...@sde.hp.com> wrote:
> ... But when all I'm trying to do is transfer files, and Kermit fails
>miserably at that (in spite of configuration suggestions from several
>experienced users), it's not worth my time to keep poking at it.
>
messages like this, which contribute nothing. If you have a specific
complaint, then send it in to ker...@columbia.edu or post it to
comp.protocols.kermit.misc. Kermit works. If it's not working for you,
there's an explanation and a solution.
- Frank
Christian Weisgerber
> Have you been able to make redirect rz/sz work on a kermit telnet connection ?
No. I don't quite know where the problem is. At first glance, 8-bit
characters *are* properly transmitted.
Joe Doupnik
Perhaps I can help unravel this puzzle.
Telnet is a protocol sitting on the top of TCP. BSD Sockets stuff
create file handles (socket handles) which refer to the TCP level and not
to the top (application level) of Telnet. C Kermit passes the handle(s)
from the TCP/IP stack to the external program, thus there is no Telnet
processor on the local end, but there is on the far end.
Telnet uses byte 255 decimal as a Telnet Options introducer, and
to send it as data instead it needs to be sent twice in a row. Recall
that Telnet processor running on the other end, and thus the external
program needs to do the doubling because there is nothing between it and
the TCP/IP stack. C Kermit does Telnet work for itself and handles Options.
X/Y/Zmodem etc external programs would need to do the same, but they don't.
Summary: the far end is running a Telnet processor, the near end
isn't, the other end interprets as command (IAC) a 255 byte and starts
Options negotiations, 255 255 comes out of the other end as a single 255.
C Kermit does not offer a Telnet interface to external programs.
Joe D.
Chuck Forsberg WA7KGX
>In article <D4EGw...@omen.COM> c...@omen.COM (Chuck Forsberg WA7KGX) writes:
>
> Kermit fans must only be interested in sending text files,
> otherwise they's notice that Kermit throughput drops way down
> when sending compressed files over 7 bit networks that eat
> control characters. But what would one expect for a protocol
> whose flagship programs generally default to destroying
> compressed files?
>
>This is not fair. Kermit is a complete terminal emulation and
>communications package, free and thoroughly tested on an incredible
>variety of platforms. On my Sparc's at work I regularly get 1200 cps,
>and only about a few percent more for zmodem when downloading to or
>from MIT. And the kermit is much more robust on bad lines. So set it
>to binary transfer and *leave it that way*.
>
> It's a bit disingenuous to claim that Kermit sends files nearly as
> fast as ZMODEM and also works over 7-bit links without mentioning
> Kermit can't do both at the same time.
>
>What? Yes it does. I do so regularly.
You get the same speed with Kermit over a 7-bit path downloading
GIF files as you do with ZMODEM over an 8-bit path?
BTW Kermit is not free.
Freedom of Speech
: >In article <D4EGw...@omen.COM> c...@omen.COM (Chuck Forsberg WA7KGX) writes:
: >
: > Kermit fans must only be interested in sending text files,
: > otherwise they's notice that Kermit throughput drops way down
: > when sending compressed files over 7 bit networks that eat
: > control characters. But what would one expect for a protocol
: > whose flagship programs generally default to destroying
: > compressed files?
: >
: >This is not fair. Kermit is a complete terminal emulation and
: >communications package, free and thoroughly tested on an incredible
: >variety of platforms. On my Sparc's at work I regularly get 1200 cps,
: >and only about a few percent more for zmodem when downloading to or
: >from MIT. And the kermit is much more robust on bad lines. So set it
: >to binary transfer and *leave it that way*.
: >
: > It's a bit disingenuous to claim that Kermit sends files nearly as
: > fast as ZMODEM and also works over 7-bit links without mentioning
: > Kermit can't do both at the same time.
: >
: >What? Yes it does. I do so regularly.
No it doesn't. That is mathematically impossible.
Plus, Kermit is excruitiatingly slow!
: You get the same speed with Kermit over a 7-bit path downloading
: GIF files as you do with ZMODEM over an 8-bit path?
Maybe he's got Kermit Mobyturbo? ;-)
: BTW Kermit is not free.
: --
: Chuck Forsberg WA7KGX c...@omen.COM 503-621-3406 FAX:-3735
: Omen Technology Inc "The High Reliability Software"
: Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, GSZ and DSZ
: TeleGodzilla BBS: 503-621-3746 FTP: ftp.cs.pdx.edu pub/zmodem
--
-Zames Zichent Zichicelli II
Steven Institute of Technology
puma
>
>You get the same speed with Kermit over a 7-bit path downloading
>GIF files as you do with ZMODEM over an 8-bit path?
That wouldn't be a fair comparison anyway, if you have a 7-bit path you
have a 7-bit path.
Earl H. Kinmonth
: Chuck Forsberg WA7KGX (c...@omen.COM) wrote:
: : In article <RAOUL.95F...@primavera.mit.edu> ra...@athena.mit.edu (Nico Garcia) writes:
: : >In article <D4EGw...@omen.COM> c...@omen.COM (Chuck Forsberg WA7KGX) writes:
: : > It's a bit disingenuous to claim that Kermit sends files nearly as
: : > fast as ZMODEM and also works over 7-bit links without mentioning
: : > Kermit can't do both at the same time.
: : >
: : >What? Yes it does. I do so regularly.
: No it doesn't. That is mathematically impossible.
: Plus, Kermit is excruitiatingly slow!
: : BTW Kermit is not free.
kermit defaults are extremely conservative and oriented to the worst
case seven-bit path. if you take the trouble to read the kermit
documentation including the separate item on performance tuning, you
can bring kermit very close to zmodem performance on eight-bit paths.
zmodem won't work at all (in my experience) on seven-bit paths, at least
not the kind you get through PADs with X25/X29. in edition kermit has
very good terminal emulation, coding translation for a number of languages
(Hebrew, Japanese, etc.), a very useful scripting language.
kermit is about as free as any software can get (exclusive of your
time).
Lawrence Kirby
jp...@sunc.shef.ac.uk "Earl H. Kinmonth" writes:
>zmodem won't work at all (in my experience) on seven-bit paths, at least
>not the kind you get through PADs with X25/X29.
ZMODEM works fine over a triple-X PAD, so long as the PAD is set up correctly
(which the host could quite reasonaby do when ZMODEM is started). Of course
there may be limitation in another part of the link or even in the host
itself which prevent ZMODEM working but there is no inherent problem with
X.25/X.29.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
tds...@kuhub.cc.ukans.edu
Two things: One, the only thing that you must pay for is the full
documentation. Columbia University's MS-DOS Kermit v 3.14 comes
with quite a bit of documentation built-in, so if you don't need
to do anything fancy you don't have to purchase the book. The same
statement applies to C-Kermit 5A(190).
Two, the philosophy of the developers is, "First make it work, then
make it fast." Real Kermit (as opposed to some kludgy half-baked
add-on supplied by some cheesy comm. software house) can be customized
to suit the particular communication needs of a site. If you have
crappy POTS lines, Kermit is robust enough to communicate through the
noise. It will be slow, but slow is better than not at all. If you
have good lines, Kermit can be made to use large packets and sliding
windows so that overhead is cut to a minimum. Also, if you know what
control characters must be prefixed in order to ensure that some piece
of hardware in the data path doesn't barf, you can tell Kermit to
unprefix the rest of them. Here at KU we go through Cisco terminal
servers that have a max rate of 38,400 bps. I have yet to find out
what control characters I can safely unprefix, but even with the
limitation of full control character prefixing and a 38,400 data rate
on the server I get about 1200cps on compressed files and 3300cps on
plain text.
One other nice thing is that I can transfer files to and from an Amdahl
5890-300E that I connect to through a 7171 protocol converter. For
ZMODEM, it might just as well be Sanskrit--it can't do it.
Chuck's been blowin' an' goin' about the virtues of ZMODEM (actually,
he's just been bagging on Kermit and its developers) over in the
Kermit group ever since Columbia University published a set of
benchmarks. The only thing that I can figure is that he's pissed off
'cause a bunch of ivory-tower types showed him up. He just shouldn't
have brought a Gremlin to the Daytona 500.
I'd set flames to /dev/null, but I'm on VMS.
BTW: don't believe me? FTP the stuff from Columbia (sorry, don't
remember the address offhand), set send pack and receive pack to
~1000, set window 4, set flow RTS/CTS (if your provider supports it),
and play for a little while. These settings are not optimized, but they
will be much faster than Kermit's bulletproof default of 94 byte packets.
I say bulletproof 'cause about the only way you're going to make Kermit
fail when left at default settings is if you unplug your modem. Heck,
even if you do unplug it mid-transfer, the next time you connect you can
continue with the transfer where you left off.
Troy Smith
Earl H. Kinmonth
: In article <3jcnnb$2...@hippo.shef.ac.uk>
: jp...@sunc.shef.ac.uk "Earl H. Kinmonth" writes:
: ZMODEM works fine over a triple-X PAD, so long as the PAD is set up correctly
: (which the host could quite reasonaby do when ZMODEM is started). Of course
: there may be limitation in another part of the link or even in the host
: itself which prevent ZMODEM working but there is no inherent problem with
: X.25/X.29.
As configured at the University of Sheffield, a ^P was (I don't use
PADs now) significant. zmodem has these and the transmission would
always break off after 13 or 14 packets.
c...@omen.com
>Lawrence Kirby (fr...@genesis.demon.co.uk) wrote:
>: In article <3jcnnb$2...@hippo.shef.ac.uk>
>: jp...@sunc.shef.ac.uk "Earl H. Kinmonth" writes:
>
>: ZMODEM works fine over a triple-X PAD, so long as the PAD is set up correctly
>: (which the host could quite reasonaby do when ZMODEM is started). Of course
>: there may be limitation in another part of the link or even in the host
>: itself which prevent ZMODEM working but there is no inherent problem with
>: X.25/X.29.
>
>As configured at the University of Sheffield, a ^P was (I don't use
>PADs now) significant. zmodem has these and the transmission would
>always break off after 13 or 14 packets.
You must mean XMODEM! ZMODEM in dial-out applications escapes (protects)
both ^P and ^P+0200.
c...@omen.com
>
>Chuck's been blowin' an' goin' about the virtues of ZMODEM (actually,
>he's just been bagging on Kermit and its developers) over in the
>Kermit group ever since Columbia University published a set of
>benchmarks. The only thing that I can figure is that he's pissed off
>'cause a bunch of ivory-tower types showed him up. He just shouldn't
>have brought a Gremlin to the Daytona 500.
They "showed me up" with a bogus set of benchmarks that were disproven
at the public Protocol Shootout. Unlike the public Protocol Shootout,
Columbia University has not agree to repeat their benchmarks in a fair,
public test. Until they do (or admit their benchmarks are flawed), I
shall continue to offer a "second opinion".
Earl H. Kinmonth
: In article <3jfk98$q...@hippo.shef.ac.uk> jp...@sunc.shef.ac.uk writes:
: >Lawrence Kirby (fr...@genesis.demon.co.uk) wrote:
: >: In article <3jcnnb$2...@hippo.shef.ac.uk>
: >: jp...@sunc.shef.ac.uk "Earl H. Kinmonth" writes:
: >As configured at the University of Sheffield, a ^P was (I don't use
: >PADs now) significant. zmodem has these and the transmission would
: >always break off after 13 or 14 packets.
: You must mean XMODEM! ZMODEM in dial-out applications escapes (protects)
: both ^P and ^P+0200.
I was using rzsz invoked as sz. It always failed after the first
dozen or so packets.
c...@omen.com
>c...@omen.com writes:
>
>> You must mean XMODEM! ZMODEM in dial-out applications escapes (protects)
>> both ^P and ^P+0200.
>
>that are floating around don't.> ZConnect muss sterben!
Wrong. It's part of the original spec. Please read it before spreading more
misinformation.
Matt Brenner
: c...@omen.com writes:
: > You must mean XMODEM! ZMODEM in dial-out applications escapes (protects)
: > both ^P and ^P+0200.
: Maybe proprietary ZModem implementations do so. The free ZModems
: that are floating around don't.
: --
Actually, I think you're both right! Page 13 of ZMODEM.DOC (contained
in YZMODEM.ZIP) clearly states that:
020 0220
021 0221
023 0223
get escaped with ZDLE (030). Yet the function,
zsendline ()
in zm.c (also in YZMODEM.ZIP) does NOT escape 020 or 0220!
In all fairness, however, ZMODEM.DOC is a model of disorgani-
zation, circumlocution, and ambiguity. The accompanying code (e.g.
zm.c) is a case study in unstructured and inefficient programming.
I have posted, repeatedly, asking for a clear description of
the ZMODEM protocol, to no avail. I ask again, "Can anyone direct
me to a clear and complete description of the protocol?"
---------------------------------------------------------------------
Matt Brenner
Structured Software Systems, Inc. E-Mail : bre...@infi.net
3084 Brickhouse Court Telephone : (804) 486-6880
Virginia Beach, VA 23452 (USA) Move-It!/Fax: (804) 486-6752
c...@omen.com
>Christian Weisgerber (na...@mips.pfalz.de) wrote:
>: c...@omen.com writes:
>
>: > You must mean XMODEM! ZMODEM in dial-out applications escapes (protects)
>: > both ^P and ^P+0200.
>
>: Maybe proprietary ZModem implementations do so. The free ZModems
>: that are floating around don't.
>
>: --
>Actually, I think you're both right! Page 13 of ZMODEM.DOC (contained
>in YZMODEM.ZIP) clearly states that:
>
> 020 0220
> 021 0221
> 023 0223
>
>get escaped with ZDLE (030). Yet the function,
>
> zsendline ()
>
>in zm.c (also in YZMODEM.ZIP) does NOT escape 020 or 0220!
020 and 0220 are not escaped in recent rzsz 3.xx because rz/sz are
host dial-in server programs that do not need to escape these characters.
> In all fairness, however, ZMODEM.DOC is a model of disorgani-
>zation, circumlocution, and ambiguity. The accompanying code (e.g.
>zm.c) is a case study in unstructured and inefficient programming.
The majority of CPU load running rz/sz is from the serial i/o
overhead. I suggest you compare the CPU overhead and
performance of the current rzsz.tlb and C-Kermit on a MicroVAX
II before you make idiot claims about inefficient programs.
> I have posted, repeatedly, asking for a clear description of
>the ZMODEM protocol, to no avail. I ask again, "Can anyone direct
>me to a clear and complete description of the protocol?"
It's exactly the same place a publicly available complete description
of the current Kermit protocol is: In your fantasies.
Every time the question of a glorious ZMODEM description perfectly
understandable by novices comes up I ask for volunteers to write grant
applications to support such a noble project. Now is a good time for Mr.
Brenner to do something useful instead of whimpering because he can't
find the "think work" he longs for handed to him on a silver platter.
If Brenner can't figure out ZMODEM and doesn't wish to license software
from Omen, I'd prefer he'd stick with Kermit and leave ZMODEM alone.
>---------------------------------------------------------------------
>Matt Brenner
>Structured Software Systems, Inc. E-Mail : bre...@infi.net
>3084 Brickhouse Court Telephone : (804) 486-6880
>Virginia Beach, VA 23452 (USA) Move-It!/Fax: (804) 486-6752
--
Dr. Klaus Wolferts
> In article <3jn0o0$n...@mips.pfalz.de> na...@mips.pfalz.de (Christian Weisgerber) writes:
> >c...@omen.com writes:
> >
> >> You must mean XMODEM! ZMODEM in dial-out applications escapes (protects)
> >> both ^P and ^P+0200.
> >
> >Maybe proprietary ZModem implementations do so. The free ZModems
> >that are floating around don't.
>
> misinformation.
There is _no_ fault in naddys statement.
He did not post "the ZModem specs don't escape those PAD control chars".
He posted that "free ZModem implementations floating around don't" do so.
These are two different facts concerning the same problem.
Read the statements posted here before bashing their posters!
Klaus
____ __ __ __ __ __
| \ | |/ / | | /| | / / Dr.-Ing. Klaus Wolferts, d...@wolferts.sub.de
| | | | | / | |/ | |/ / Ing'Buro f. EDV + Elektronik, Tel. +49 721 706016
| d| | | k| \ | w| /| | / Mitteltorstr. 45, Fax: +49 721 706017
|____/ |__|\_\ |__|/ |__|/ D-76149 Karlsruhe (Nrt), Germany 49N03'02" 8E22'58"
Matt Brenner
: > In all fairness, however, ZMODEM.DOC is a model of disorgani-
: >zation, circumlocution, and ambiguity. The accompanying code (e.g.
: >zm.c) is a case study in unstructured and inefficient programming.
: The majority of CPU load running rz/sz is from the serial i/o
: overhead. I suggest you compare the CPU overhead and
: performance of the current rzsz.tlb and C-Kermit on a MicroVAX
Apparently caf cannot read any better than he can write. I said the
code is unstructured and inefficent. Any competent C programmer can
see from the countless goto statements and the useless pre- and post-
increments that the code is poorly written.
: Every time the question of a glorious ZMODEM description perfectly
: understandable by novices comes up I ask for volunteers to write grant
: applications to support such a noble project.
If caf could put a noun and a verb together to construct a sentence he
wouldn't require a grant (for remedial writing skills training?). There
is nothing noble about documenting ones work.
Furthermore, I'm not looking for a description suitable for novices,
only one that's complete. Unlike caf, I don't wish to devote my entire
life to something as small as zmodem. I simply wish to understand
it and move on. I've gotten quite a bit of mail from other people also
looking for a proper description of zmodem.
: Now is a good time for Mr.
: Brenner to do something useful instead of whimpering because he can't
: find the "think work" he longs for handed to him on a silver platter.
Only a twisted mind could view obtaining a clear description of a
protocol in the public domain as a search for "think work."
: If Brenner can't figure out ZMODEM and doesn't wish to license software
: from Omen, I'd prefer he'd stick with Kermit and leave ZMODEM alone.
Your preferences are unimportant. The reason for writing a protocol
description is to describe the protocol, so people don't have to
reverse engineer it. But caf such a self-serving miscreant, apparently
unable to clearly describe the one thing most dear to him.
As for licensing software from Omen, jugding by the C code in
YZMODEM.ZIP, the author should be arrested for impersonating
a programmer.
c...@omen.com
Every freeware or shareware rz/sz published by Omen Technology up to 3.24
escapes 020 and 0220. That includes every royalty free version of rz/sz
Omen ever published.
It's in ECU version 330.
Weisgerber's statement about free ZMODEM programs is incorrect.
The current version rz/sz 3.38 does not escape 020 0r 0220. Rz and sz are
host only programs which do not need to escape these characters. Note
that rz/sz 3.xx are shareware, not free.
c...@omen.com
>c...@omen.com wrote:
>
>: > In all fairness, however, ZMODEM.DOC is a model of disorgani-
>: >zation, circumlocution, and ambiguity. The accompanying code (e.g.
>: >zm.c) is a case study in unstructured and inefficient programming.
>
>: The majority of CPU load running rz/sz is from the serial i/o
>: overhead. I suggest you compare the CPU overhead and
>: performance of the current rzsz.tlb and C-Kermit on a MicroVAX
>
>Apparently caf cannot read any better than he can write. I said the
>code is unstructured and inefficent. Any competent C programmer can
>see from the countless goto statements and the useless pre- and post-
>increments that the code is poorly written.
Goto statements may not be the latest in politically correct coding
style, but they are not necessarily inefficient, particularly with
the compilers is use when the original rz/sz code was written.
Again, I suggest one compare the CPU overhead and performance of
current rzsz.tlb and C-Kermit versions on a MicroVAX II before
posting puerile flames about "efficiency".
As for the comment about "useless pre- and post-increments",
I am reminded of compilers that complain that putchar has no effect.
>: Every time the question of a glorious ZMODEM description perfectly
>: understandable by novices comes up I ask for volunteers to write grant
>: applications to support such a noble project.
>
>If caf could put a noun and a verb together to construct a sentence he
>wouldn't require a grant (for remedial writing skills training?). There
>is nothing noble about documenting ones work.
What's wrong about that sentence is that Brenner doesn't like its message.
>Furthermore, I'm not looking for a description suitable for novices,
>only one that's complete. Unlike caf, I don't wish to devote my entire
>life to something as small as zmodem. I simply wish to understand
>it and move on. I've gotten quite a bit of mail from other people also
>looking for a proper description of zmodem.
If Brenner is too lazy to learn ZMODEM from the available PD materials, he
should stick with Kermit. According to its author, Kermit beats ZMODEM
every time, and none of my critics on this thread have complained about
the available Kermit protocol descriptions.
>: Now is a good time for Mr.
>: Brenner to do something useful instead of whimpering because he can't
>: find the "think work" he longs for handed to him on a silver platter.
>
>Only a twisted mind could view obtaining a clear description of a
>protocol in the public domain as a search for "think work."
OK Brenner, how much are you willing to pay for it?
>: If Brenner can't figure out ZMODEM and doesn't wish to license software
>: from Omen, I'd prefer he'd stick with Kermit and leave ZMODEM alone.
>
>Your preferences are unimportant. The reason for writing a protocol
>description is to describe the protocol, so people don't have to
>reverse engineer it. But caf such a self-serving miscreant, apparently
>unable to clearly describe the one thing most dear to him.
Again, Brenner, how much are you willing to pay for it?
I understand Brenner don't wish to dedicate the rest of his life
to ZMODEM. Likewise, I don't wish to dedicate a single minute
of my life to enrich rude, selfish competitors such as Brenner.
>As for licensing software from Omen, jugding by the C code in
>YZMODEM.ZIP, the author should be arrested for impersonating
>a programmer.
YZMODEM.ZIP should be compared to other completely royalty free file
transfer code published in its 1986 timeframe.
Omen's ZMODEM-90(Tm) software is not the same thing.
Gary Fritz
: ... before you make idiot claims about inefficient programs.
: It's exactly the same place ... In your fantasies.
: Now is a good time for Mr.
: Brenner to do something useful instead of whimpering because he can't
: find the "think work" he longs for handed to him on a silver platter.
: If Brenner can't figure out ZMODEM and doesn't wish to license software
: from Omen, I'd prefer he'd stick with Kermit and leave ZMODEM alone.
etc. ad nauseum.
Mr. Forsberg: I suggest you remember that you are interacting in a
public forum, and that you are presenting a fairly repugnant image of
yourself and Omen Technology. If you insist on acting in such an
obnoxious manner, you may find very FEW people are willing to license
software from Omen.
c...@omen.com
>
>Mr. Forsberg: I suggest you remember that you are interacting in a
>public forum, and that you are presenting a fairly repugnant image of
>yourself and Omen Technology. If you insist on acting in such an
>obnoxious manner, you may find very FEW people are willing to license
>software from Omen.
I am sorry if my comments appear remotely as obnoxious as the
flames that have been directed at me in this thread.
c...@omen.com
>> In article <3jn0o0$n...@mips.pfalz.de> na...@mips.pfalz.de (Christian Weisgerber) writes:
>> >c...@omen.com writes:
>> >
>> >> You must mean XMODEM! ZMODEM in dial-out applications escapes (protects)
>> >> both ^P and ^P+0200.
>> >
>> >Maybe proprietary ZModem implementations do so. The free ZModems
>> >that are floating around don't.
>>
>> Wrong. It's part of the original spec. Please read it before spreading more
>> misinformation.
>
>There is _no_ fault in naddys statement.
>He did not post "the ZModem specs don't escape those PAD control chars".
>He posted that "free ZModem implementations floating around don't" do so.
>These are two different facts concerning the same problem.
>Read the statements posted here before bashing their posters!
Every free version of rz/sz escapes both of those characters.
Every free implementation of ZMODEM that I have seen escapes
both of those characters.
There may exist hacked implementations for dial-out use that don't
escape those characters, but I haven't seen any that claim to
support the standard ZMODEM protocol.
If an implementation for dial-out does not default to escaping
these characters it isn't ZMODEM, by definition.
Robert Nicholson
version that does the following.
Simply transfers files to PC comms software from unix. ie. not the old
versions of sz and rz that support -1 through tip but rather a version
of an executable that simply allows you to specify the device an file
to transfer it accross.
Can somebody tell me how you use these old versions with tip?
ie. when you wish to receive you just do a ~$ rz -1 don't you?
What about sending?
--
"Mary ate a little lamb and punk rock isn't dead"
(PGP key: send email with Subject: request pgp key)