Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!hp-pcd!hpcvra!bobwo
From: bobwo@hpcvra.CV.HP.COM (Bob Worsley)
Newsgroups: comp.sys.handhelds
Subject: Re: Confirmed bug in HP-48SX Kermit implemenation
Message-ID: <25590007@hpcvra.CV.HP.COM>
Date: 31 May 90 17:54:22 GMT
References: <1836@uc.msc.umn.edu>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 43

/ hpcvra:comp.sys.handhelds / fin@norge.unet.umn.edu (Craig A. Finseth) /  2:04 pm  May 24, 1990 /

>	 2. The "M" following the "#" has its high bit set since the
>	 first two packets shown agreed not to do 8th bit prefixing.
>	 Your tracing equipment is probably like mine (doesn't show the
>	 high bit even when set to 8 bit characters).  Character code
>	 141 decimal is 8D hex which looks like a control character
>	 with the high bit set, hence the preceding "#" control quote
>	 character and the transformation from 8D to CD (not 4D).
>
>The program would show a cd hex character as ~M, not M.  Hence, this
>difference would be visible.

I found a way to trace the transactions in hex, and the "->" character
is in fact sent as "cd" hex (the high bit _is_ set).  This is further
confirmed by the funny character displayed on the PC or Mac receive file
name.  Therefore the checksum sent by the HP 48 is correct.


> The actual problem was as described: we created an object that had a
> right arrow (141 decimal) character in its name.  When trying to
> upload the object to a Macintosh, we received a checksum error (using
> the HP-supplied Kermit on the Macintosh).  We then tried the
> HP-supplied Kermit on an IBM PC.  Same problem.  We then tried
> PC/InterComm (whcih has the tracing capabilities).  Same problem.  All
> of these programs transfer other object properly.  PC/InterComm
> reported a checksum computation problem.  (I don't recall whether the
> Kermit programs indicated the type of error.)

I tried uploading an object with the same name to a Mac, and the upload
failed until I asked for a dialog on each file and entered a normal name
in place of the received name with the funny character in it.  When I
renamed the object in this manner it transferred with no problems.

The real problem appears to be that the Mac doesn't like a name with the
character 141 in it.  I suspect it won't like any of the characters in the
range 128 - 159 since some systems consider them to be control characters.

The Kermit on my PC automatically renamed the object to CRXP so it had no
problem receiving it.  

The HP 48 does support file renaming when sending or receiving, so you could
also avoid the problem on the 48 end.