leung@uicsrd.csrd.uiuc.edu (11/13/88)
Did anybody get part2 of the Procomm Test Drive ok? Our copy didn't make
it in very good shape. Would somebody e-mail a copy if I'm the only one.
Thanks,
Bruce
----------------------------------------------------------------------
Bruce Leung leung@uicsrd.csrd.uiuc.edu
Univ. of Illinois {seismo,pur-ee}!uiucdcs!uicsrd!leungleung@uicsrd.csrd.uiuc.edu (11/15/88)
I got it! (Thanks again Frank.) If anybody else didn't get it I'd
be happy to send a copy if you e-mail me (several people already have).
----------------------------------------------------------------------
Bruce Leung leung@uicsrd.csrd.uiuc.edu
Univ. of Illinois {seismo,pur-ee}!uiucdcs!uicsrd!leungcnee@wright.EDU (Cheng-Lee Nee) (11/15/88)
in article <26300001@uicsrd.csrd.uiuc.edu>, leung@uicsrd.csrd.uiuc.edu says: > Did anybody get part2 of the Procomm Test Drive ok? Our copy didn't make > it in very good shape. Would somebody e-mail a copy if I'm the only one. The part 2 of Procomm Test Drive didn't show up at this site. Would someone please post it? Cheng-Lee Nee
jio@cpsc55.ATT.COM (James Odom) (11/15/88)
From article <26300001@uicsrd.csrd.uiuc.edu>, by leung@uicsrd.csrd.uiuc.edu: > > Did anybody get part2 of the Procomm Test Drive ok? Our copy didn't make > Bruce Leung leung@uicsrd.csrd.uiuc.edu > Univ. of Illinois {seismo,pur-ee}!uiucdcs!uicsrd!leung It didn't make it to our location at all. +------------------------------------------------------------------------+ |James I. Odom | |AT&T CPSC Denver, Co Voice: (303) 889-0211 | |ATTMAIL: JODOM Compuserve: 70070,137 uucp: att!cpsc55!jio | | BIX: jodom SOURCE: TCC375 | |------------------------------------------------------------------------| |Disclaimer: Any opinions expressed are my own etc. | +------------------------------------------------------------------------+
svaepiz@eva.slu.se (Epizootologen p} SVA) (11/16/88)
Yes, oh yes! More requests for the part 2 of Procomm Plus! It didn't make it to us either, so please could someone forward it to me (or to the list since apparently several did miss it).
t-harish@microsoft.UUCP (Harish Pillay) (11/19/88)
Our site received all the part of Procomm Test Drive but when we tried to
uudecode it, it kept failing - "End not found". The "end" is in the
file and someone e-mailed us part 8 and that did not help either. We
are using the uudecode under DOS that was posted to comp.binaries.ibm.pc
recently.
Would appreciate if some kind soul out there could e-mail us all the 8
parts.
Please send it to the following address:
t-harish@microsoft.uucp
Thanks netlanders!
Harish Pillay
Microsoft Corporation850347s@aucs.UUCP (Hume Smith) (11/20/88)
> Yes, oh yes! More requests for the part 2 of Procomm Plus! It > didn't make it to us either, so please could someone forward it > to me (or to the list since apparently several did miss it). Count me in! We missed parts 1, 2, and 3. 850347s@Acadia should be BITNET if need be
news@ziggy.UUCP (Usenet Admin) (11/20/88)
Add one more lost soul to the list that didn't get part 2 of the test drive. Could some kind person repost it, or mail a copy to me? Thanks in advance -- John Mullins Frederick, Md
anderson@secd.cs.umd.edu (Gary Anderson) (11/21/88)
I would like use Procomm with emacs. Procomm uses the esc key as vt220's pf1 key. When I try the suggested ^[ to get escape, Procomm beeps or emacs just bell's back at me and then includes a 'P' in the file I'm editing. Any suggestions on how one can use emacs with this new or for that matter the old Procomm? Thanks in advance, Gary
fmb@ihlpa.ATT.COM (Botelho) (11/21/88)
You guessed it right! No part 2. Would someone who thinks they are local, send me mail and I'll ask them to send me part 2? Thanks, -- Fernando Botelho AT&T Bell Laboratories IW-3D-113 Naperville, Illinois ihlpa!fmb 312/979-7376 This signature is NOT greater than 4 lines!
leung@uicsrd.csrd.uiuc.edu (11/22/88)
Several people have e-mailed requests for various parts of Procomm. If you
haven't heard from me it means that my mail bounced back. Either try to
send mail to me again (including your most reliable address) or try to get
it elsewhere.
In particular, I had trouble reaching wright.edu and SVAEPIZ at EVA.SLU.SE
----------------------------------------------------------------------
Bruce Leung leung@uicsrd.csrd.uiuc.edu
Univ. of Illinois {seismo,pur-ee}!uiucdcs!uicsrd!leung
He who has imagination without learning has wings but no feet.dwf@pnbell.UUCP (Don Ford) (11/24/88)
From article <1380@aucs.UUCP>, by 850347s@aucs.UUCP (Hume Smith): >> Yes, oh yes! More requests for the part 2 of Procomm Plus! It > Count me in! We missed parts 1, 2, and 3. Yet another request: We missed parts 2 and 8 of Procomm Plus Test Drive. Thanks in advance, Don Ford {......}!uw-june!pilchuck!apcisea!pnbell!dwf
pb@idca.tds.PHILIPS.nl (Peter Brouwer) (11/25/88)
>>> Yes, oh yes! More requests for the part 2 of Procomm Plus! It >> Count me in! We missed parts 1, 2, and 3. >Yet another request: We missed parts 2 and 8 of Procomm Plus Test Drive. I am not able to de-arc the decoded file . I am getting errors after four files have been found so I suspect part two or three is corrupted. After the file pcplus.hlp things go wrong, The pcplus.hlp gives crc errors and is corrupted as well Seeing the number of posting about problems, I think i reposting of the package might be justified. -- # Peter Brouwer, ## # Philips TDS, Dept SSP-V2 ## voice +31 55 432523 # P.O. Box 245 ## UUCP address ..!mcvax!philapd!pb # 7300 AE Apeldoorn, The Netherlands ## Internet pb@idca.tds.philips.nl
lane@dalcs.UUCP (John Wright/Dr. Pat Lane) (11/26/88)
From article <1380@aucs.UUCP>, by 850347s@aucs.UUCP (Hume Smith): >> Yes, oh yes! More requests for the part 2 of Procomm Plus! > Count me in! We missed parts 1, 2, and 3. Same here. >Thanks in advance, ditto! -- John Wright ///////////////// Phone: 902-424-3805 or 902-424-6527 Post: c/o Dr Pat Lane, Biology Dept, Dalhousie U, Halifax N.S., CANADA B3H-4H8 Cdn/Bitnet: lane@cs.dal.cdn Arpa: lane%dalcs.uucp@uunet.uu.net Uucp: lane@dalcs.uucp or {uunet,watmath,utai,garfield}!dalcs!lane
850347s@aucs.UUCP (Hume Smith) (11/30/88)
In article <193@ssp2.idca.tds.philips.nl> pb@idca.tds.PHILIPS.nl (Peter Brouwer) almost, but not quite, wrote: >I am not able to de-arc the decoded file. pcplus.hlp is corrupted. >Seeing the number of posting about problems, I think a reposting might be >justified. The holes in our posting of PC+TD were patched for me today and my archive has the same problems. Sigh. Maybe it would be nicer to just buy the thing.
doug@primo.hig.hawaii.edu (Doug Myhre) (12/01/88)
>From 850347s@aucs.UUCP (Hume Smith) >The holes in our posting of PC+TD were patched for me today and my archive >has the same problems. Sigh. Maybe it would be nicer to just buy the thing. That sure would make Datastorm Technologies happier. doug
karl@ddsw1.MCS.COM (Karl Denninger) (12/02/88)
In article <1414@aucs.UUCP> 850347s@aucs.UUCP (Hume Smith) writes: >In article <193@ssp2.idca.tds.philips.nl> pb@idca.tds.PHILIPS.nl (Peter >Brouwer) almost, but not quite, wrote: >>I am not able to de-arc the decoded file. pcplus.hlp is corrupted. >>Seeing the number of posting about problems, I think a reposting might be >>justified. > >The holes in our posting of PC+TD were patched for me today and my archive >has the same problems. Sigh. Maybe it would be nicer to just buy the thing. Don't bother, at least if you care about the protocol transfer items. 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. 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. Get (and support) Zcomm. It'll do all that Procomm does, it works, and it's shareware. It's not cute, but darn does it get the job done (it even works at 38400 and other obscene baud rates). Other advantages include nearly every protocol known to man (Zmodem, xmodem, ymodem, kermit, etc), a real VT100 emulation that works, even on a VAX under VMS, and complete programmability. I'm not affiliated with either the Zcomm or Procomm people, but we will be registering Zcomm soon -- it works flawlessly, unlike all the other packages I've tried. -- 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"
malloy@nprdc.arpa (Sean Malloy) (12/05/88)
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 used PCPLUSTD for some four months while waiting for my copy of Procomm+ to arrive, and never had any problems with sending multiple files, either before or after I received my copy of Procomm+. On several occasions, I've downloaded fifteen or twenty files in a single batch command, and the only problem I've ever had is with noisy phone lines. |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. Of course, if Zcomm ever turns out to have a bug, I'm _sure_ that you'll drop it like a hot potato, just the same way you dropped PCPLUSTD when you found a bug in it. @END(SARCASM) Sean Malloy Navy Personnel Research & Development Center San Diego, CA 92152-6800 malloy@nprdc.arpa
karl@ddsw1.MCS.COM (Karl Denninger) (12/06/88)
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"
karl@ddsw1.MCS.COM (Karl Denninger) (12/07/88)
Public crow eating ceremonies are being held........ It appears that I made a misstatement here in this forum a couple of days ago; this posting is to correct the inaccuracies. In article <2354@ddsw1.MCS.COM> karl@ddsw1.MCS.COM(Karl Denninger) writes: >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. I need to eat some crow here. BOTH our VMS and UNIX versions are broken at least slightly; the Unix one chews up long pathnames, and the VMS one is just plain wierd. After some experimentation, we found that an argument list of files that exceed 80 characters sometimes causes the Unix implementation to fail. This turns out to be two file paths in one application, where we are passing a bona-fide 500-byte or so buffer. Interesting enough, it doesn't fail all the time, and I must have just hit the combination while checking w/Zcomm...(yikes!) We'll be looking into this one further.... I hereby retract everything except what you see repeated below from articles: <2293@ddsw1.MCS.COM> <2354@ddsw1.MCS.COM> >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). > >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. Also: I am set up for a VT100 here (as in termcap). Just switched into VT102 mode -- and got "blink" on the entire page! Was I mistaken in my belief that a VT102 was a VT100 superset? >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 ;-). 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. Thanks to the kind gentelman who pointed out my earlier error (and stimulated some more testing under different conditions). -- 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"