[comp.unix.microport] UUCP problems

abcscnge@csuna.UUCP (Scott "The Pseudo-Hacker" Neugroschl) (03/25/88)

When attempting to run UUCP from a IBM XENIX 1.0 system to an SCO XENIX V 2.2.1
system, the IBM system calls up and logs in, and the SCO system responds with

Shere

and then times out the IBM system.  I also can't seem to get 2 IBM 1.0 systems
to talk via UUCP.  Any suggestions?
-- 
Scott "The Pseudo-Hacker" Neugroschl
UUCP:  ...!ihnp4!csun!csuna!abcscnge
-- "They also surf who stand on waves"
-- Disclaimers?  We don't need no stinking disclaimers!!!

davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) (03/28/88)

In article <1113@csuna.UUCP> abcscnge@csuna.UUCP (Scott "The Pseudo Hacker" Neugroschl) writes:
| When attempting to run UUCP from a IBM XENIX 1.0 system to an SCO
| XENIX V 2.2.1 system, the IBM system calls up and logs in, and the
| SCO system responds with
| 
| Shere
| 
| and then times out the IBM system.  I also can't seem to get 2 IBM 1.0 systems
| to talk via UUCP.  Any suggestions?

Having spent several weeks finding a similar problem, I would suspect
parity is the problem. Particularly if the call working in one direction
and not the other. If that's the case let me know, I think I have the
solution to the problem.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

mike@ists (Mike Clarkson) (03/29/88)

In article <10126@steinmetz.steinmetz.ge.com>, davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) writes:
| In article <1113@csuna.UUCP| abcscnge@csuna.UUCP (Scott "The Pseudo Hacker" Neugroschl) writes:
| | When attempting to run UUCP from a IBM XENIX 1.0 system to an SCO
| | XENIX V 2.2.1 system, the IBM system calls up and logs in, and the
| | SCO system responds with
| | 
| | Shere
| | 
| | and then times out the IBM system.  I also can't seem to get 2 IBM 1.0 systems
| | to talk via UUCP.  Any suggestions?
| 
| Having spent several weeks finding a similar problem, I would suspect
| parity is the problem. Particularly if the call working in one direction
| and not the other. If that's the case let me know, I think I have the
| solution to the problem.

Very likely.  SCO defaults its port to no parity, while most other
Unixes default to even parity.  You have 2 choices; either change the
parity for your port to even using /etc/gettydefs, or at the IBM end,
try adding 

	"" P_ZERO 

at the beginning of the chat script, after the phone number.  This (may)
tell the IBM uucico to start up using parity = none.

-- 
Mike Clarkson						mike@ists.UUCP
Institute for Space and Terrestrial Science
York University, North York, Ontario,
CANADA M3J 1P3						(416) 736-5611

res@ihlpe.ATT.COM (Rich Strebendt, AT&T-DSG @ Indian Hill West) (03/31/88)

In article <1113@csuna.UUCP>, abcscnge@csuna.UUCP (Scott "The Pseudo-Hacker" Neugroschl) writes:
> When attempting to run UUCP from a IBM XENIX 1.0 system to an SCO XENIX V 2.2.1
> system, the IBM system calls up and logs in, and the SCO system responds with
> 
> Shere
> 
> and then times out the IBM system.  I also can't seem to get 2 IBM 1.0 systems
> to talk via UUCP.  Any suggestions?

Sure ... install a large eyebolt in the top of each IBM system, fill
each with concrete, and put the IBM systems into use as boat anchors.

(Sorry, I couldn't resist the open invitation -- but I did keep my
suggestion CLEAN!!!)

				Rich Strebendt 
				...!ihnp4![iwsl6|ihlpe|ihaxa]!res

davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) (03/31/88)

In article <175@ists> mike@ists (Mike Clarkson) writes:
>
>Very likely.  SCO defaults its port to no parity, while most other
>Unixes default to even parity.  You have 2 choices; either change the
>parity for your port to even using /etc/gettydefs, or at the IBM end,

It's even worse than that... the older version of Xenix use 7E1, while
the more recent 2.2.x series uses 8N1.

My solution, rather than change the default back to 7E1 was to create a
little program called "uu7E1" (clever, right) which resets the parity
and execs uucico. This is then made the login shell for certain ids
which don't like no parity.

The long term solution was, as you mentioned, to have the BSD machine
calling me change to no parity.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

fred@cdin-1.uucp (Fred Rump) (04/08/88)

In article <1113@csuna.UUCP>, abcscnge@csuna.UUCP (Scott "The Pseudo-Hacker" Neugroschl) writes:
> When attempting to run UUCP from a IBM XENIX 1.0 system to an SCO XENIX V 2.2.1
> system, the IBM system calls up and logs in, and the SCO system responds with
> to talk via UUCP.  Any suggestions?       GET RID OF 1.0 !!!
> -- 
> Scott "The Pseudo-Hacker" Neugroschl
> UUCP:  ...!ihnp4!csun!csuna!abcscnge

My my, there are still 1.0 IBM's out there.
We have a few IBM 2.0's left. We didn't even like that product and stopped
selling it as not usable in customer environments.
It's been SCO all the way. At least they talk to us.
Anybody want ibm 2.0? Brand spanking new.
ihnp4!bpa!cdin-1!fred
in Philly

dave@viper.Lynx.MN.Org (David Messer) (07/29/88)

I've been having problems with UUCP under Microport ever since
version 1.3.8.

What happens is that it makes the connection ok but then it
drops the line for no reason (that I can see.)  It puts
the message "25 (INTREXIT)" in the log file and, if I run
uucico with the -x5 option, it ends with "cntrl 8" as a
debugging message.  It also seems to be much more likely to
crap-out if I am using the -x5 option.

Do any of you know what is going on?  I'd especially like to
know what these messages mean.

Thanks for any help you can give me.
-- 
If you can't convince |   David Messer - (dave@Lynx.MN.Org)
them, confuse them.   |   Lynx Data Systems
   -- Harry S Truman  | 
                      |   amdahl   --!bungia!viper!dave
                      |   hpda    /

Copyright 1988 David Messer -- All Rights Reserved
This work may be freely copied.  Any restrictions on
redistribution of this work are prohibited.