Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ncar!unmvax!gatech!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: v01i007 Procomm Test Drive (part2)
Summary: Crow eating time on one count of three.  (Karl eats it in public)
Message-ID: <2364@ddsw1.MCS.COM>
Date: 6 Dec 88 18:43:19 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> <2354@ddsw1.MCS.COM>
Reply-To: karl@ddsw1.MCS.COM(Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 76

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"