Path: utzoo!attcan!uunet!image.soe.clarkson.edu!news
From: help@kendra.kew.com (Drew Derbyshire)
Newsgroups: comp.mail.uucp
Subject: Re: Problems with DECUS UUCP and UUPC communications
Message-ID: <1990May29.024510.9854@sun.soe.clarkson.edu>
Date: 29 May 90 02:45:10 GMT
References: <27@thehulk.dmc.com>
Sender: ahd@clutx.clarkson.edu (Drew Derbyshire)
Reply-To: help@kendra.kew.com (Drew Derbyshire)
Organization: Clarkson University, Potsdam, NY
Lines: 42

From article <27@thehulk.dmc.com>, by munroe@thehulk.dmc.com (Dick Munroe, Doyle Munroe Consultants, Inc.):
> My thanks to Andre Wood (andre@hern.mv.com) who, in passing,
> mentioned seeing this problem before and saved me a lot of time
> hunting for it.
> 
> All implementations of UUPC send the following during the initial
> g protocol handshake:
> 
> 	\000\020 handshake message \000
> 
> For those of you who want the fix, in dcpsys.c in function wmsg,
> change:
> 
> 	swrite("\0\020",2) ;
> 
> to
> 
> 	swrite("\020",1) ;
> 
> and the problem will go away.

This is a bad idea.  

The reason is that wmsg is the driver for most messages through UUPC,
and will cause sync'ed messages to include the extra \000 character, which
may impact your performance.  The fix should go in startup(), I think
(I don't read news on kendra, which is where my UUPC source is).  I'll
fix the distribution copy of UUPC when someone gives me the fix for
startup() and tested it.

Later ... Looking at the UUPC/extended 1.07j source, changes need to
made around lines 433 and 466 of dcpsys.c to add a direct call to
swrite to terminate the message with a \000.  

I'd personally fix DECUS UUCP.  However, I'll add the fix to
UUPC/extended 1.07k if some writes it up and tests it.

Drew Derbyshire
UUPC/extended maintainer

Internet: 	help@kendra.kew.com