Path: utzoo!utgpu!watmath!clyde!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: v01i007 Procomm Test Drive (part2) Summary: Procomm Plus Test Drive .vs. Zcomm - PCP comes up short (warning=heat) Message-ID: <2354@ddsw1.MCS.COM> Date: 5 Dec 88 16:14:44 GMT References: <1380@aucs.UUCP> <323@pnbell.UUCP> <193@ssp2.idca.tds.philips.nl> <1414@aucs.UUCP> <2293@ddsw1.MCS.COM> <1127@skinner.nprdc.arpa> Reply-To: karl@ddsw1.MCS.COM(Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 131 In article <1127@skinner.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes: >In article <2293@ddsw1.MCS.COM> karl@ddsw1.MCS.COM(Karl Denninger) writes: >|Kermit protocol is STILL broken, at least in batch mode. It will now send or >|receive a single file, but when trying to receive more than one file it >|terminates the other end after the first file has been sent (grrr....). To >|duplicate, go into kermit on a Unix (or other working) machine, type >|"send file1 file2" and then tell local PComm+TD to receive. You'll get >|one file. > >I would suggest that you look at the copy of kermit on the Unix end >before dropping all the blame on Datastorm. I have looked at KERMIT on the Unix end, and on the VMS end, and...... Yes, I did indeed test this out before posting to the net at large. It failed nice and consistently in "receive" mode, although the "server get" seemed to work correctly. All this was on a 9600-baud direct line -- no modem noise possible! My original thought was that kermit on the Unix side WAS broken -- until I tried it with Zcomm. Were you in server mode, or had you commanded the other end to transmit (as in "kermit -is *", or "send *" from the "Kermit>" prompt)? If so, then we have an even "better" situation -- it works sometimes! Wonderful! I also noted that Datastorm hasn't added support for either large packets or windows in their kermit implementation. Just slightly behind the times; 90 character packets are a little slow on high-speed nets, especially without windowed support..... they do support 3-byte CRCs though so even though it's slow, you'll probably get the entire file intact (if you get any of it at all). Zcomm (and others) have both of these right. On the _same_ systems, I can give an identical download command -- and get ALL the files. How can it be the Unix (or VMS) end that is broken under these circumstances? >|Why, why, why, Datastorm? It can't be that bad; Zcomm got it right.... I >|won't bother picking on them about the emulations (some of which are STILL >|broken as well); when I found the download problem the package got 'rm'd >|from our DOS area. > >@BEGIN(SARCASM) Why single out PCPLUSTD? If _any_ program you use has >_any_ bugs, don't bother to inform the authors, just take it off the >system. After all, your time, and the time of your compatriots, >shouldn't have to be taken up with the menial tasks of working around >a bug or informing the authors of the bug; after all, it's the >_developer's_ fault that they didn't find the bug; they're _obviously_ >only interested in your money rather than delivering a quality >product. I see; now, during this COMMERCIAL, I am supposed to overlook what are, to me, serious flaws. Even better - I should learn how to work around them -- myself. Don't you see the problem with this? PC Plus TD is not a "here it is, use it" package -- IT'S AN ADVERTISEMENT. PCPLUSTD is a demo package for a commercial product. It was distributed over the network. Procomm and Datastorm have a TERRIBLE reputation with regards to their protocol downloads; every version I have ever laid hands on has had problems in this area. Kermit is the worst offender -- it didn't used to work at ALL unless you set up for space parity (good luck on some Unix machines doing this; 8 bits, 1 stop and SPACE parity is impossible on a lot of hardware!) Now it "sorta" works. I'm not impressed. If this was a PD release I'd be far less perturbed; in that case I just might figure out how to "work around" the problems. Given that Datastorm has had well over two years to get this one portion of the product right, and has consistantly failed to do so, I think I have a valid complaint. With 2.4.1 and 2.4.2 Procomms I did report the problems (as did a number of other people). Have you looked at all the emulations yet? Got a '386 to run the program on? With some emulations, the "screen clear" can take nearly an entire second -- on a 19200 serial line (ie: you can see it "wipe it clean")! I admit this is emulation-dependant (if you select "ADM3" it's nice and fast, as is VTxx, but look out for some of the others!). Datastorm's "115400" baud rates look rather ludicrous when the package can't even keep up with a 19200 terminal line on a 10 Mhz AT! I don't even want to think about what a PC system would be like; thank God we don't have anything that slow in daily use around here anymore. Keeping up with the serial flow is VERY important when you can't XOFF -- if you need the entire domain of characters (8-bit transmission) XOFF's tend to really screw things up ;-). Perhaps I just expect too much, or perhaps I am spoiled. Let me tell you what I know of Zcomm: o It automatically "keys" on a download; you don't have to give a receive command. ZCOMM determines the proper protocol and automatically uses it. 'Fer instance, on a kermit transmission all you do is send the file from the host; Zcomm automatically picks up on the protocol and grabs the file for you without prompting (unless it needs to ask if overwriting existing files is ok). The only exception I am aware of is Xmodem, which makes sense given that Xmodem does not encode the filename in the transmission. Filenames which do not fit the DOS namespace are converted appropriately. This works for Zmodem, Ymodem and Kermit protocols (and may for others; those are the only ones I use regularly). o It contains support for 16550 SIO chips (no idea if PCPlusTD does). o The VT100 emulation works very well, including the keypad. Even on an 83-key board it's usable (which is QUITE startling). On a 101 it's great; there are different keymaps for the different keyboards and they are supplied with the package! Just about the only missing feature is double high/wide characters; hard to do without going into graphics mode! o It has a common protocol, Zmodem, which can achieve really nice performance on such nasty networks as Telenet and other packet-switched communications media; these are very common these days! o Everything and anything can be done through an incredibly powerful scripting language; files can be "sourced" to effectively replay a sequence. o There's a large scrollback buffer (10K in the shareware "leader", 65K or so in the "real" copy) that comes in mighty handy when you're online and "miss" something that scrolled off too fast. My only complaint here is that the scrollback doesn't preserve terminal attributes (ie: you see escape sequences rather than their effect w/a given emulation). o It's fast -- I'd call it a tie between Zcomm and PC/VT for "most efficient"; both can keep up at 19200 without trouble without hardware assist. Zcomm, with 16550's, ought to handle 56kbaud (38400 does work without help, but occasionally Xoffs) :-) I can use it at 19200, on a garden-variety clone, in Foxbase + (Xenix) -- a notoriously picky setup which will NOT tolerate soft flow control! Finally: It's $40 to register (and remove the "unregistered" from your screen when you call it up). Btw: I've no connection to nor relationship with either Datastorm (Procomm +) or Omen Technologies (Zcomm), and these are my views, not necessarially the company's. -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"