[comp.unix.xenix] UUCP problems between HDB UUCP and XENIX UUCP

eric@diox (Eric Pouyoul) (05/17/88)

I have to connect with UUCP two systems. One is a 286 running
IBM XENIX, witch have some UUCP link with other systems, like VAXs under
BSD 4.3 and some *UNIX* systems.

The second machine is a Motorola under a native System V.3 release 4.
With this package, UUCP is the famous HDB UUCP. I have a little documentation
to configure this UUCP, but, when XENIX call the Motorola, all is ok, but
nothing done after the "shere= ..." message.

I don't know where is the bug, in the HDB configuration or in my physical
link (XENIX tty driver is not so good).

I'm sure about the electrical connexion (I can use it with kermit).

Did anyone make this link (XENIX <-> SystemV.3) ?

Thank's

Eric
-- 
_____________________________________________________________________________
Eric Pouyoul   / MICROPREST  61 Avenue de Paris  94800 VILLEJUIF
UUCP :  { ..seismo!mcvax!inria!diox!eric  }
_____________________________________________________________________________

mikes@ncoast.UUCP (Mike Squires) (05/31/88)

In article <223@diox> eric@diox (Eric Pouyoul) writes:
>I have to connect with UUCP two systems. One is a 286 running
>IBM XENIX, witch have some UUCP link with other systems, like VAXs under
>BSD 4.3 and some *UNIX* systems.
>
>The second machine is a Motorola under a native System V.3 release 4.
>With this package, UUCP is the famous HDB UUCP. I have a little documentation
>to configure this UUCP, but, when XENIX call the Motorola, all is ok, but
>nothing done after the "shere= ..." message.
>
This may not be the answer to your specific problem, but I have found that my
Tandy 6000 under 68K XENIX 3.2 (3.0 development system) will fail in the way
described (connection dropped after startup) when the first task queued is a
uucp file copy.  Sending a piece of mail "solves" the problem.  This has occurred
between the 6000 and systems that I know to be running HDB and those that I
suspect to be running HDB.  It appears only when the 6000 is polling the HDB
system, and not vice versa.

Mike Squires Allegheny College Meadville, PA 16335 814 724 3360
uucp: ..!mandrill!ncoast!{mikes,peng!sir-alan!mikes} or ..!pitt!sir-alan!mikes
BITNET: mikes%sir-alan@pitt.UUCP (VAX) MIKES AT SIR-ALAN!PITT.UUCP (IBM)
known in the SCA as Sir Alan Culross, Earl Marshall of the Middle Kingdon

clif@clif.UUCP (Clif Flynt) (06/04/88)

In article <7835@ncoast.UUCP> mikes@ncoast.UUCP (Mike Squires) writes:
>Tandy 6000 under 68K XENIX 3.2 (3.0 development system) will fail in the way
>described (connection dropped after startup) when the first task queued is a
>uucp file copy.  Sending a piece of mail "solves" the problem.  This has occurred
>between the 6000 and systems that I know to be running HDB and those that I
>suspect to be running HDB.  It appears only when the 6000 is polling the HDB
>system, and not vice versa.
>
>Mike Squires Allegheny College Meadville, PA 16335 814 724 3360
>uucp: ..!mandrill!ncoast!{mikes,peng!sir-alan!mikes} or ..!pitt!sir-alan!mikes
>BITNET: mikes%sir-alan@pitt.UUCP (VAX) MIKES AT SIR-ALAN!PITT.UUCP (IBM)
>known in the SCA as Sir Alan Culross, Earl Marshall of the Middle Kingdon

I had similar problems when I was first setting up my uport HDB system,
and trying to get all my old programs off my Tandy M16.  I could only
transfer stuff if the HDB system initiated the transfer.

When you call in to a HDB system, the stuff in the Permissions file is
checked a lot more thoroughly than when you call out.  (Like, I don't 
know if it's checked at all when a HDB system calls out.)

The system you call should have a setup something like this for your
system in it's Permissions file.  If you don't, then you'll have trouble
talking unless they call you. 

	LOGNAME=uuname \
        MACHINE=system_name \	
        REQUEST=yes READ=/usr/spool/uucppublic WRITE=/usr/spool/uucppublic \
        COMMANDS=rmail:rnews \
        SENDFILES=yes

Hope this helps...
-- 
-------------------------------- Clif Flynt --------------------------------
--------------------------- uunet!umix!clif!clif ---------------------------
---------------- This space reserved for a witty disclaimer ----------------