wehr@fmeed1.UUCP (Bruce Wehr) (09/15/89)
In article <630010@apl-em.UUCP>, dunlap@apl-em.UUCP (John Dunlap) writes: > We've been running 500's for years with dial-in/dial-out on the > same port. Works just like the manual says -- perfect. I've got HP's dial-in/dial-out facility working fine, too. I don't know about *perfect*, but fine. One thing I've observed (and it may be something I'm doing wrong, but) is that cu doesn't keep searching for a line when it finds one busy. We have several serial lines set up for in/out use. Interactive users could be using any number of them. If uucico finds a line that's in use (the open fails), it goes on down the list in the Devices file until it finds one available, or finds them all busy and quits. However, it seems that cu gives up immediately if the first line it tries is busy. Is there something I could be doing wrong, or is this just the way it is? -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, DPTC Room LN081, Dearborn, Michigan 48121 (313)845-3039
dunlap@apl-em.UUCP (John Dunlap) (09/19/89)
I agree, uucp and cu should try the next phone number when a busy signal is detected on the first. Our uucp and cu both skip over the ports in use. Here is a section of my L.sys file: <sysname> <time>[,<retry>] <dev> <speed> <phone> <logininfo> ampmsp Any,5 tty03 4800 tty03 "" EOT ogin:-EOT-ogin: uucp word: uupasswd ampmsp Any,5 ACUVADIC3450 1200 57598 ogin:-EOT-ogin: uucp word: uupasswd ampmsp Any,5 ACUVADIC3450 1200 57599 ogin:-EOT-ogin: uucp word: uupasswd ampmsp Any,5 ACUVADIC3450 1200 52250 ogin:-EOT-ogin: uucp word: uupasswd ampmsp Any,5 ACUVADIC3450 1200 30911 ogin:-EOT-ogin: uucp word: uupasswd When the direct line tty03 is in use telephone number 57598 is dialed. However, I think the other phone numbers are never used. We have two modems which will dial out and if one of them is in use the other is used. John Dunlap dunlap@apl-em.apl.washington.edu
rdg@hpfcmgw.HP.COM (Rob Gardner) (09/20/89)
> I've got HP's dial-in/dial-out facility working fine, too. I don't know > about *perfect*, but fine. One thing I've observed (and it may be > something I'm doing wrong, but) is that cu doesn't keep searching for a > line when it finds one busy. > > Is there something I could be doing wrong, or is this just the way it > is? You're not doing anything wrong. Very sorry, but that's simply a bug that's been around since dinosaurs roamed the earth. This is actually one situation where I think uugetty might help, since it creates lock files for incoming lines. Rob
wehr@fmeed1.UUCP (Bruce Wehr) (09/21/89)
In article <1080084@hpfcmgw.HP.COM>, rdg@hpfcmgw.HP.COM (Rob Gardner) writes: > > [...] cu doesn't keep searching for a line when it finds one busy. > > [...] that's simply a bug that's been around since dinosaurs roamed the earth. That's unfortunate. > This is actually one situation where I think uugetty might help, > since it creates lock files for incoming lines. That's what I was hoping for. After playing around with it a bit, I found that *that* doesn't help either :-( -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, DPTC Room LN081, Dearborn, Michigan 48121 (313)845-3039