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.