alexis@panix.uucp (Alexis Rosen) (03/05/91)
I've been using UUCP very heavily on this A/UX Mac IIx now for several months.
(In fact, this may be the most heavily uucp-loaded Mac around...) As the load
on the machine continues to grow, I've been noticing some fairly obnoxious
behavior. When the system is fairly busy (several active users), I frequently
see log entries like this:
cmcl2!notes (3/4-19:24:45) (C,15402,21) IN SEND/SLAVE MODE (INPUT FAILURE)
cmcl2!notes (3/4-19:24:45) (C,15402,21) FAILED (conversation complete)
I'm so used to this crap that I wrote a script months ago to handle all of our
polling needs, so this isn't disastrous. But it's annoying as hell and it ties
up our telebit a lot more than it should (for some reason, this failure takes
from 5 to 30 minutes for UUCP to notice). It also doubles or triples our phone
bill, since we often need to call our feed two, three, or four times just to
do one full batch of files.
I don't think I've ever seen this behavior during the night, when few users
are on.
A rarer, but far more obnoxious bug, which I get once or twice a month, looks
like this in the log file:
cmcl2!jsb (3/4-19:28:07) (C,15598,0) REQUEST (S D.cmcl2BC3330 D.cmcl2BC3330 jsb)
cmcl2!jsb (3/4-19:31:32) (C,15598,1) BAD READ (expected 'C' got FAIL)
cmcl2!jsb (3/4-19:31:32) (C,15598,1) FAILED (conversation complete)
The bitch of it is, unlike the other bug, this is NON-RECOVERABLE. The file
(in this case D.cmcl2BC3330) is permanently lost, and the mail (or whatever
it may be) is vanished, without even an error message to the sender.
I'd like to know how many of you are being bitten by this same bug? Any ideas
on workarounds? I'm not optimistic but it can't hurt to ask. Our Mac is a IIx
with 8MB ram, 500MB of assorted Wren drives, and a bunch of modems and serial
ports. The uucp problems always occur with our telebit, running off of a
Taniwha CommCard. (I doubt the card or the telebit are responsible here though.)
BTW, if anyone wants the polling script, drop me a line. It's custom-written
for my system but it's pretty easily adaptible.
Thanks,
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexisjpm@logixwi.UUCP (Jan-Piet Mens @ Logix GmbH, Wiesbaden) (03/08/91)
In article <1991Mar5.102756.3379@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >I've been using UUCP very heavily on this A/UX Mac IIx now for several months. I am using UUCP rather heavily on a i486 box running SCO UNIX 3.2.0 >see log entries like this: >cmcl2!notes (3/4-19:24:45) (C,15402,21) IN SEND/SLAVE MODE (INPUT FAILURE) >cmcl2!notes (3/4-19:24:45) (C,15402,21) FAILED (conversation complete) This happens daily to me >I don't think I've ever seen this behavior during the night, when few users >are on. Correct! >A rarer, but far more obnoxious bug, which I get once or twice a month, looks >like this in the log file: >cmcl2!jsb (3/4-19:28:07) (C,15598,0) REQUEST (S D.cmcl2BC3330 D.cmcl2BC3330 jsb) >cmcl2!jsb (3/4-19:31:32) (C,15598,1) BAD READ (expected 'C' got FAIL) >cmcl2!jsb (3/4-19:31:32) (C,15598,1) FAILED (conversation complete) If you look at the output of `uucico -x9`, You see ten alarm calls, and then comes the failure. Any suggestions ? -- Jan-Piet Mens, Logix GmbH jpm@logixwi.UUCP Moritzstr. 50, D-6200 Wiesbaden ...!uunet!mcsun!unido!logixwi!jpm
mann@intacc.uucp (Jeff Mann) (03/12/91)
In article <1991Mar5.102756.3379@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >I've been using UUCP very heavily on this A/UX Mac IIx now for several months. >(In fact, this may be the most heavily uucp-loaded Mac around...) As the load >on the machine continues to grow, I've been noticing some fairly obnoxious >behavior. When the system is fairly busy (several active users), I frequently >see log entries like this: >cmcl2!notes (3/4-19:24:45) (C,15402,21) IN SEND/SLAVE MODE (INPUT FAILURE) >cmcl2!notes (3/4-19:24:45) (C,15402,21) FAILED (conversation complete) .... >A rarer, but far more obnoxious bug, which I get once or twice a month, looks >like this in the log file: >cmcl2!jsb (3/4-19:28:07) (C,15598,0) REQUEST (S D.cmcl2BC3330 D.cmcl2BC3330 jsb) >cmcl2!jsb (3/4-19:31:32) (C,15598,1) BAD READ (expected 'C' got FAIL) >cmcl2!jsb (3/4-19:31:32) (C,15598,1) FAILED (conversation complete) > >I'd like to know how many of you are being bitten by this same bug? Any ideas I received the same errors for a time when I was setting up uucp, they were related to a flow control problem. Since the Mac cannot support hardware flow control and modem control at the same time, and since modem control is essential for security and other reasons, you cannot use flow control at all, which means you can't use the Telebit's auto baud rate translation feature. Before I came to my senses and realised this, I tried using software flow control (XON/XOFF). Of course, you can't use software flow control with uucp. The result of doing so was the same type of error messages described above. Alexis, would you mind posting a short description of the polling script you use (or the script itself if it is short enough). I have also written some stuff which lets me successfully use a port for incoming and outgoing calls. First I have a c program called setmodem. When changing a port from incoming to outgoing, it uses init(1M) to turn the getty off for the port, turns off modem control so I can talk to the modem, and sets up parameters on the Telebit. I also have a fake uucico which calls setmodem before exec'ing the real uucico. I can post these programs, along with a few necessary changes to inittab, etc., if there is a demand for it. I think it should be portable to any A/UX system. However, I have no doubt duplicated the efforts of other A/UX users in this area, so I'd like to know what other people have done. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | The Matrix Artists' Computer Network BBS: [416] 535-7598 2400 8N1 | | ...uunet!mnetor!intacc!mann mann@intacc.uucp [416] 535-1443 Telebit 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
dittman@skbat.csc.ti.com (Eric Dittman) (03/13/91)
> I received the same errors for a time when I was setting up uucp, they were > related to a flow control problem. Since the Mac cannot support hardware > flow control and modem control at the same time, and since modem control is > essential for security and other reasons, you cannot use flow control at > all, which means you can't use the Telebit's auto baud rate translation > feature. Before I came to my senses and realised this, I tried using software > flow control (XON/XOFF). Of course, you can't use software flow control > with uucp. The result of doing so was the same type of error messages > described above. Apple should allow HSKi/HSKo for hardware flow control and GPi for carrier detect. This would be the best compromise. -- Eric Dittman Texas Instruments - Component Test Facility dittman@skitzo.csc.ti.com dittman@skbat.csc.ti.com Disclaimer: I don't speak for Texas Instruments or the Component Test Facility. I don't even speak for myself.
urlichs@smurf.sub.org (Matthias Urlichs) (03/13/91)
In comp.unix.aux, article <1991Mar12.125557.433@skbat.csc.ti.com>,
dittman@skbat.csc.ti.com (Eric Dittman) writes:
<
< Apple should allow HSKi/HSKo for hardware flow control and GPi for
< carrier detect. This would be the best compromise.
<
I second this wholeheartedly.
It's a shame that there's this perfectly workable input pin there, and A/UX
doesn't use it.
Some people need both carrier detect and hardware flow control.
I can get by without a hardware solution to get the modem to hang up, but
that doesn't work too well in the other direction...
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/unger@mitem (Tom Unger) (03/14/91)
In article <1991Mar11.190108.27114@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: >you use (or the script itself if it is short enough). I have also written >some stuff which lets me successfully use a port for incoming and >outgoing calls. First I have a c program called setmodem. When >changing a port from incoming to outgoing, it uses init(1M) to turn the >getty off for the port, turns off modem control so I can talk to the >modem, and sets up parameters on the Telebit. I also have a fake uucico >which calls setmodem before exec'ing the real uucico. I can post these >programs, along with a few necessary changes to inittab, etc., if there >is a demand for it. I think it should be portable to any A/UX system. >However, I have no doubt duplicated the efforts of other A/UX users in >this area, so I'd like to know what other people have done. I have a program called uugetty that I adapted from a program called ringback that came from: - Paul Traina (pst@anise.acc.com) adapted from work by: - Jon Zeeff (umix!b-tech!zeeff) uugetty is run from init. It initializes the modem and waits for an incomming call. When the call comes it answer the call and execs login. When the user exits init restarts uugetty. uugetty will recognize what baud rate the connection is at and set the tty accordingly. uugetty also monitors the tty for any other traffic. If anything comes through uugetty gives up the tty then falls in to a loop where it checks the existance of a uucp lock file for the tty. When the lock file goes away uugetty returns and initializes the modem. The only change this requires to the uucp system is to maybe add an extra character to the front of all chat scripts because uugetty seems to eat the first character. I can send the source code to anyone who is interested or will post it here if there is enough interest. Tom Unger unger!mitem@igc.org MITEM.
ksand@Apple.COM (Kent Sandvik) (03/14/91)
In article <1991Mar12.125557.433@skbat.csc.ti.com> dittman@skbat.csc.ti.com (Eric Dittman) writes: >Apple should allow HSKi/HSKo for hardware flow control and GPi for >carrier detect. This would be the best compromise. Most UNIX systems I've used/programmed had so buggy hardware flow control on the serial line, that XON/XOFF was the only practical solution. Speaking as an engineer who had to test many modems with HW flow control, some of them had so weird handshaking (dropping 109s and all kinds of weird high state definitions) that XON/XOFF seemed to be the compromise concerning standards. Yes, HW handshaking is faster, but with slower speeds this is marginal. For more fun info about the GPi (General Purpose input) and MacOS, please read the latest TN #286 by Craig Prouse/DTS. Kent Sandvik, MacDTS Disclaimer: Private activity on USENET
paul@taniwha.UUCP (Paul Campbell) (03/16/91)
In article <1991Mar12.125557.433@skbat.csc.ti.com> dittman@skbat.csc.ti.com (Eric Dittman) writes: > >Apple should allow HSKi/HSKo for hardware flow control and GPi for >carrier detect. This would be the best compromise. Except that just having an input for modem control doesn't do the job ... you also need a modem control output so that modem hang-ups and answers work correctly (for example so that DTR is dropped when a user logs out so that the modem gets hung up ....). Ideally Apple should have GPi and GPo (as well as HSKi and HSKo) which would make a total of 9 pins (gee - they could use a DB9 :-). Actually an even slightly smart chip engineer at Apple ought to be able to design a serial port driver chip with the RXD+/TXD+ pins able to be reprogrammed as the GPi/GPo pins when the port is being used as an RS232 port (since these pins are unused on ports used for RS232). Paul Campbell Taniwha Systems -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P "But don't we all deserve. More than a kinder and gentler fuck" - Two Nice Girls, "For the Inauguration"
alexis@panix.uucp (Alexis Rosen) (03/17/91)
mann@intacc.uucp (Jeff Mann) writes: > alexis@panix.uucp (Alexis Rosen) writes: >>I've been using UUCP very heavily on this A/UX Mac IIx now for several months. >> [...] When the system is fairly busy (several active users), I frequently >>see log entries like this: >>cmcl2!notes (3/4-19:24:45) (C,15402,21) IN SEND/SLAVE MODE (INPUT FAILURE) >>cmcl2!notes (3/4-19:24:45) (C,15402,21) FAILED (conversation complete) >.... >> [and, infrequently...] >>cmcl2!jsb (3/4-19:31:32) (C,15598,1) BAD READ (expected 'C' got FAIL) >>cmcl2!jsb (3/4-19:31:32) (C,15598,1) FAILED (conversation complete) > >I received the same errors for a time when I was setting up uucp, they were >related to a flow control problem. Since the Mac cannot support hardware >flow control and modem control at the same time, and since modem control is >essential for security and other reasons, you cannot use flow control at >all, which means you can't use the Telebit's auto baud rate translation >feature. Before I came to my senses and realised this, I tried using software >flow control (XON/XOFF). Of course, you can't use software flow control >with uucp. The result of doing so was the same type of error messages >described above. Yes. But I expect that with that kind of erroneous setup you could never transmit binary files of any significant length. That's not it- I turn off Xon/Xoff. I quote from my L.sys: "ATS48=1S58=0" >Alexis, would you mind posting a short description of the polling script >you use (or the script itself if it is short enough). I have also written Done. This went out several days ago. >some stuff which lets me successfully use a port for incoming and >outgoing calls. First I have a c program called setmodem. When >changing a port from incoming to outgoing, it uses init(1M) to turn the >getty off for the port, turns off modem control so I can talk to the >modem, and sets up parameters on the Telebit. I also have a fake uucico >which calls setmodem before exec'ing the real uucico. I can post these >programs, along with a few necessary changes to inittab, etc., if there >is a demand for it. I think it should be portable to any A/UX system. While this no doubt works fine, it's way more elaborate than you need. That's because somebody at Apple wanted things to work right, and spent some time and effort making getty Do The Right Thing. It's just too bad s/he wasn't able to clean up UUCP at the same time. As of 2.0, getty is "bidirectional" in that it understands UUCP lock files, and it won't grab a serial port it's trying to open if some other process (like uucico) grabs it first. The only reason the whole thing doesn't work automatically is that uucico is still very stupid. It doesn't know to do a "stty -modem" on its line first, and to set it back when it's done. The bottom line is that inittab need never be changed. In fact, you don't really need to write a poll script at all- you can simply wrap uucico in a script which does a stty on each side of the real uucico. The reason I use a poll script is to try calling several times. (Also, don't forget that no matter how you set things up, _something_ has to set TZ before you invoke uucico!!) Anyway, if anyone has any ideas about that SEND/SLAVE MODE problem, I'd love to hear it. I'm pretty sure Jeff was on the right track, in that _something_ is freezing up the transmission until uucico times out. I just wish I could figure out what... --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
alexis@panix.uucp (Alexis Rosen) (03/17/91)
dittman@skbat.csc.ti.com (Eric Dittman) writes: >> [Jeff Mann wrote:] Since the Mac cannot support hardware >> flow control and modem control at the same time, and since modem control is >> essential for security and other reasons, you cannot use flow control [...] > >Apple should allow HSKi/HSKo for hardware flow control and GPi for >carrier detect. This would be the best compromise. What they _should_ do is build serial ports that are capable of working right. Switching to 8 pins was just foolish. (And I know all about "cost savings" and "connector space on rear panel" arguments.) Sadly, even your suggestion won't work. Apple won't support it because on some Macs, the GPi pin isn't even connected any more. Go figure. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
alexis@panix.uucp (Alexis Rosen) (03/17/91)
urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.unix.aux, article <1991Mar12.125557.433@skbat.csc.ti.com>, > dittman@skbat.csc.ti.com (Eric Dittman) writes: >< Apple should allow HSKi/HSKo for hardware flow control and GPi for >< carrier detect. This would be the best compromise. >< >I second this wholeheartedly. > >It's a shame that there's this perfectly workable input pin there, and A/UX >doesn't use it. > >Some people need both carrier detect and hardware flow control. >I can get by without a hardware solution to get the modem to hang up, but >that doesn't work too well in the other direction... As I wrote previously, Apple doesn't even have GPi on some Macs. On the other hand, there is one solution. Digiboard makes 4 and 8 port serial boards for A/UX that support both DTR/DCD and RTS/CTS (HSKi/HSKo). They come with hydra cables that have real DB-25s at the ends! I don't know how this works yet but I'm installing one tomorrow on Panix. I'll let you know. (BTW, they also support Berkeley-style line control. So the whole issue of dialin-dialout is moot.) --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
alexis@panix.uucp (Alexis Rosen) (03/17/91)
In article <1991Mar13.172541.1413@mitem> unger@mitem (Tom Unger) writes: >I have a program called uugetty that I adapted from a program called ringback >that came from: > - Paul Traina (pst@anise.acc.com) > adapted from work by: > - Jon Zeeff (umix!b-tech!zeeff) > >uugetty is run from init. It initializes the modem and waits for an >incomming call. When the call comes it answer the call and execs >login. When the user exits init restarts uugetty. uugetty will >recognize what baud rate the connection is at and set the tty accordingly. > >uugetty also monitors the tty for any other traffic. If anything comes >through uugetty gives up the tty then falls in to a loop where it >checks the existance of a uucp lock file for the tty. When the lock >file goes away uugetty returns and initializes the modem. The getty that comes with A/UX 2.0 does all of this too. (1.x did _not_, which is why all that was necessary.) The question is, does it turn on/off modem control on the line? If it does, then you've got something. Otherwise, you still have to wrap uucico. To be honest, I'd still rather wrap uucico, as I wrote earlier... This actually brings up another question. What would _really_ be useful is a replacement to uucico. After all, that's where all the trouble lies. Anybody got one that works as-is with the rest of A/UX's UUCP system? --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
ksand@Apple.COM (Kent Sandvik) (03/18/91)
In article <1991Mar17.082904.1993@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: > > dittman@skbat.csc.ti.com (Eric Dittman) writes: >>> [Jeff Mann wrote:] Since the Mac cannot support hardware >>> flow control and modem control at the same time, and since modem control is >>> essential for security and other reasons, you cannot use flow control [...] >> >>Apple should allow HSKi/HSKo for hardware flow control and GPi for >>carrier detect. This would be the best compromise. > >What they _should_ do is build serial ports that are capable of working >right. Switching to 8 pins was just foolish. (And I know all about "cost >savings" and "connector space on rear panel" arguments.) > >Sadly, even your suggestion won't work. Apple won't support it because on >some Macs, the GPi pin isn't even connected any more. Go figure. FYI, that's the LC. DTS did not like this thing, but it was too late. We are looking at doing something with the CTB tools so the GPi line could be used for 109 signalling concerning 109 signals from modems (maybe that's already done, I have not checked into it lately so sorry if I'm wrong). Kent -- Disclaimer: Private activity on the Net, in no way connected to any company. Zippy++ says: END, END; or END. is sure clearer than "}".
dittman@skbat.csc.ti.com (Eric Dittman) (03/18/91)
In article <1991Mar17.083537.2098@panix.uucp>, alexis@panix.uucp (Alexis Rosen) writes: > As I wrote previously, Apple doesn't even have GPi on some Macs. According to the _Guide to the Macintosh Family Hardware_ book by Apple Computer, Inc., all Macintosh computers with the DIN-8 that are capable of running A/UX (the SE/30, Macintosh II, IIx, IIcx, IIci, IIfx) have GPi. The only system capable of running A/UX that's not listed is the IIsi, because the IIsi wasn't around when the 2nd edition was printed, but I don't think Apple would remove GPi from the IIsi. -- Eric Dittman Texas Instruments - Component Test Facility dittman@skitzo.csc.ti.com dittman@skbat.csc.ti.com Disclaimer: I don't speak for Texas Instruments or the Component Test Facility. I don't even speak for myself.
urlichs@smurf.sub.org (Matthias Urlichs) (03/20/91)
In comp.unix.aux, article <793@taniwha.UUCP>, paul@taniwha.UUCP (Paul Campbell) writes: < In article <1991Mar12.125557.433@skbat.csc.ti.com> dittman@skbat.csc.ti.com (Eric Dittman) writes: < > < >Apple should allow HSKi/HSKo for hardware flow control and GPi for < >carrier detect. This would be the best compromise. < < Except that just having an input for modem control doesn't do the job ... you < also need a modem control output so that modem hang-ups and answers work < correctly (for example so that DTR is dropped when a user logs out so that < the modem gets hung up ....). Ideally Apple should have GPi and GPo (as well < as HSKi and HSKo) which would make a total of 9 pins (gee - they could use a < DB9 :-). < Not strictly necessary, as you can make getty say "\d+++\dATZ\r\d" to the modem. For user logins, change the +++ to something the tty driver doesn't echo, like NULs. -- I know that this is not a very good solution, but it's the only one possible with current hardware. < Actually an even slightly smart chip engineer at Apple ought to be able to < design a serial port driver chip with the RXD+/TXD+ pins able to be < reprogrammed as the GPi/GPo pins when the port is being used as an RS232 < port (since these pins are unused on ports used for RS232). < Good idea... it may even be possible to auto-detect the difference. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/
urlichs@smurf.sub.org (Matthias Urlichs) (03/20/91)
In comp.unix.aux, article <1991Mar17.084301.2192@panix.uucp>,
alexis@panix.uucp (Alexis Rosen) writes:
<
< This actually brings up another question. What would _really_ be useful is a
< replacement to uucico. After all, that's where all the trouble lies. Anybody
< got one that works as-is with the rest of A/UX's UUCP system?
<
Actually it's possible to use BSD 4.3 uucp.
I'm doing that here under the university's BSD source license -- I don't know
whether the binaries can be shared. Some of the dialers (which are separate
programs) also have some nasty AT&T copyright claimers in their source.
I have hacked at it quite a bit to get it what I want it to do.
If it's legally possible, I could conceivably make it available. Anybody know?
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/