Path: utzoo!censor!comspec!humvax!becker!geac!jtsv16!uunet!cs.utexas.edu!usc!apple!oliveb!tymix!3comvax!bridge2!ngg
From: ngg@bridge2.ESD.3Com.COM (Norman Goodger)
Newsgroups: comp.sys.mac.comm
Subject: Re: White Knight zmodem problems
Keywords: White Knight, Zmodem
Message-ID: <2533@bridge2.ESD.3Com.COM>
Date: 4 May 90 23:00:02 GMT
References: <1990May1.150650.2226@chinet.chi.il.us> <2524@bridge2.ESD.3Com.COM> <1990May3.162251.21166@chinet.chi.il.us>
Distribution: usa
Organization: 3Com Corp., Mt. View, CA
Lines: 20

In article <1990May3.162251.21166@chinet.chi.il.us> henry@chinet.chi.il.us (Henry C. Schmitt) writes:
>
>I've had this problem too!  I also thought it was a fluke but
>apparently it might not be.  Could it be some interaction with sz
>here at chinet?  I'll try running some tests and see what happens.
>  H3nry C. Schmitt     | CompuServe: 72275,1456  (Rarely)

	After a few msgs of feedback, it appears that the solution
	to the problem of where zmodem is placing resumed data into
	a resource fork and not the data fork where it belongs is
	to set WK to disable Macbinary or the use Macbinary for no
	Files setting. I will chat at Scott and see if this should
	be the solution or if there is a change required in the code
	to solve this problem. More Later...

-- 
Norm Goodger				SysOp - MacInfo BBS @415-795-8862
3Com Corp.				Co-SysOp FreeSoft RT - GEnie.
Enterprise Systems Division             (I disclaim anything and everything)
UUCP: {3comvax,auspex,sun}!bridge2!ngg  Internet: ngg@bridge2.ESD.3Com.COM