how@milhow1uunet.UU.NET (Mike Howard) (04/10/89)
SCO Xenix 2.3.1 HDB UUCP and SCO Xenix 2.2.3 UUCP use different methods to implement `uucp file machine1!machine2!directory'. If the Host machine is 2.3.1 and machine1 is 2.2.3 (or vice versa) the requested copy is denied. Example: uuto file machine1!machine2!user HDB UUCP: generates the following `uux' command: uucp -C file machine2!~/receive/user/hostmachine This fails on `XQT DENIED' if machine1 is a 2.2.3 UUCP without putting `uucp' in L.cmds. [putting uucp in L.cmds seems suicidal]. OLD UUCP: generates the request: S file machine2!~receive/user/hostmachine This fails on `PERMISSION (DENIED)' where the request is translated to: hostmachine!file --> machine1!machine2!~receive/user/hostmachine ----------------------------???????????------------------------------- Anyone else run into this? Any work around(s)? -- Mike Howard uunet!milhow1!how
einhorn@hydra.unm.edu (E Drew Einhorn ADV.SCI.Inc) (08/29/90)
I am trying to get a news feed set up at work. We have an office in Arlington, Va that is trying to set up a news feed from uunet and they are supposed to feed me. Unfortuneately the Arlington office is having severe uucp problems. They are running UNIX System V/386 Release 3.2 from Bell Technologies (I believe Bell Technologies was gobbled up by Intel). When a large file is uucp'ed onto their system everything goes fine for the first few kbytes of the file then everything shifts to SLOW mode. I believe the scheduler on their machine is starving the uucico process for cpu time. I tried to transfer a test file onto their system. During the first few seconds the lights on my modem blinked normally. (We have Telebit T2500s on each end. I believe they are correctly configured). After a few seconds the RD and SD lights go dark. I can see my machine periodically time out and retransmit. Every once in a while their machine wakes up and a few packets are exchanged. I suggested the system administrator in arlington to try manually executing uucio with nice boosting the priority. Didn't seem to make any difference we saw the same behavior on my modem lights. When they uucp a file onto my system the file transfer goes at a reasonable rate which seems to confirm my belief that the modems are correctly configured. My machine talks to other machines successfully. Any suggestions? -- einhorn@hydra.unm.edu
cpcahil@virtech.uucp (Conor P. Cahill) (08/29/90)
In article <1990Aug28.215058.16147@ariel.unm.edu> einhorn@hydra.unm.edu (E Drew Einhorn ADV.SCI.Inc) writes: >When a large file is uucp'ed onto their system everything goes fine for >the first few kbytes of the file then everything shifts to SLOW mode. >I believe the scheduler on their machine is starving the uucico process >for cpu time. > >Any suggestions? Ensure that xon/xoff flow control is off on the Bell tech machine. Ensure that you have an intelligent i/o port on the Bell tech machine Ensure that you have the latest and greatest drivers for the BT. Ensure that both the CLIST and TTHOG tunable parameters are not too low (just try doubling them to see if it has a positive effect). If it still fails, lower the baud rate between the modem and the system to see if that fixes the overflow problems. If it still fails, run uucico with -x99 (lots of debugging output) on both sides to see if you can tell what the problem is. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
wiljo@freesid.mamnix.quest.sub.org (Wiljo Heinen) (09/03/90)
einhorn@hydra.unm.edu (E Drew Einhorn ADV.SCI.Inc) writes: [feed setup] >They are running UNIX System V/386 Release 3.2 from Bell Technologies >(I believe Bell Technologies was gobbled up by Intel). >When a large file is uucp'ed onto their system everything goes fine for >the first few kbytes of the file then everything shifts to SLOW mode. >I believe the scheduler on their machine is starving the uucico process >for cpu time. >I tried to transfer a test file onto their system. During the first >few seconds the lights on my modem blinked normally. (We have Telebit >T2500s on each end. I believe they are correctly configured). After a >few seconds the RD and SD lights go dark. I can see my machine >periodically time out and retransmit. Every once in a while their >machine wakes up and a few packets are exchanged. For me this looks like the standard asy-driver prob. With R3.2 the asy driver just doesn't catch up with the 19200 or so baud. It loses bytes which then gives rise to new syncing between the two ends and a re-send request. Sending is not the prob, as T2500 always catches the data. (Just try uucico -x for debugging and watch out for errors/resends). I had the same probs with ISC 2.0.2 until I switched to 16550A SIOs and the FASY fast asy drivers. Now everything is fine. >Any suggestions? well - these were my $0.02 worth... cheers Wiljo -- snail-mail: | e-mail: | tel. lines: | | Wiljo Heinen | wiljo@freesid.ruhr.sub.org | voice: +49-231-162837 Rittershausstr. 55 | wheinen@ipkama.ka.sub.org | fax: +49-231-140192