paulf@Umunhum.STANFORD.EDU (Paul A. Flaherty, N9FZX) (05/22/87)
This might save someone from a few hours of frustration. I'm running a binary - only V7 on a pdp-11/23 box. Add to that a CTS 2424 2400 bps Hayes compatible, which turned out to be a bit too compatible. My expect - send sequence looked something like: OK-AT^M-OK ATDT5551212 gin:--gin:-^M-gin: uucp After sending the dial string to the modem, uucico would patiently wait about thirty seconds, looking for gin:. Since the call was still in progress at the end of the waiting period, uucico then proceeded to the "null send". Unfortunately, "--" results in a ^M being send down the line, which, true to the Hayes standard, hangs up the call. So, I was stuck, since I didn't have a true "null send". The solution to this (suggested by my roommate, a med student at that...) was to drop the modem into command mode after dialing; with the CTS 2424, this is done as follows: OK-AT^M-OK ATDT5551212; 1200-ATO^M-1200 ^M gin:--gin: uucp A pretty bizarre little hack, but it does work. So, if you're ever stuck with a very primitive dialing scriptor, check it out. -- Paul Flaherty, N9FZX >->-_->-> Computer Systems Lab -- Stanford University | Project ARPAnet: paulf@shasta.Stanford.EDU ===== OSCAR AMnet: N9FZX @ N6IIU =====
csg@pyramid.UUCP (05/22/87)
In article <1685@Umunhum.STANFORD.EDU> paulf@Umunhum.STANFORD.EDU (Paul A. Flaherty, N9FZX) writes: >Unfortunately, "--" results in a ^M being send down the line, which, true >to the Hayes standard, hangs up the call. So, I was stuck, since I didn't >have a true "null send". Yes you do. Instead of: >OK-AT^M-OK ATDT5551212 gin:--gin:-^M-gin: uucp the correct form for v7 uucp is: OK-AT\r\c-OK ATDT5551212 gin:-\c-gin:-\r\c-gin: uucp and even better is: OK-AT\r\c-OK ATDT5551212 CONNECT-\c-CONNECT \c gin:-\r\c-gin: uucp \c means "don't send the default newline." And note that v7 ends each "send" with a '\n' character (aka ^J), not a '\r' (aka ^M). <csg>
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (05/26/87)
In article <2445@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) replies to article <1685@Umunhum.STANFORD.EDU> paulf@Umunhum.STANFORD.EDU (Paul A. Flaherty, N9FZX) by suggesting an alternative chat script: >and even better is: > >OK-AT\r\c-OK ATDT5551212 CONNECT-\c-CONNECT \c gin:-\r\c-gin: uucp > >\c means "don't send the default newline." And note that v7 ends each "send" >with a '\n' character (aka ^J), not a '\r' (aka ^M). Yes. It is even better yet to \always/ include the terminating character and not depend upon the particular implementation. I have even encountered an implementation that had \no/ terminating character automaticly included; that one was particularly irritating. Thus, an even better approach is: AT\r\c OK-AT\r\c-OK ATDT5551212\r\c CONNECT-\c-CONNECT \c gin:-\r\c-gin: uucp\r\c Personally, I do not like my scripts to wait as long as this one would -- that "CONNECT-\c-CONNECT" will wait about 90 seconds before dropping the connection; I have had cases where remote modems would pick up the phone but not provide carrier, leaving me with lots of short calls that accomplished nothing. First I knew about it was when my monthly long-distance phone bill went up $300..... The way to control this is to add a limited amount of delay with the \d option (I believe this has been in all UUCPs since V7, but I don't know about V6), making our little example: AT\r\c OK-AT\r\c-OK ATDT5551212\r\d\d\d\d\d\c CONNECT \c gin:-\r\c-gin: uucp\r\c which would add five to ten seconds of delay to the dial sequence. (Note that the delay occurs between the \r that starts the modem dialing and the \c that ends that part of the chat script.) More can be added as is needed. For my soapbox comment of the evening, I'll point out that it's extremely irritating that these chat scripts don't offer a finer control of the delay timing. Five seconds is more than adequate for almost every circumstance, but occasionally you need much longer times; it's really too bad that you can't just say "wait n seconds" when you need a delay. Instead you end up waiting too long (do you really need to wait 45 seconds to know that the modem isn't going to resond to the "AT"?) or not long enough (international calls can take more than 45 seconds to go through). There are other paridgms that have been devleoped that are simpler, more intuitive, and more powerful -- I'd like to see UUCP adopt something better. Chat scripts are almost as much of a dark art as sendmail configuration scripts, and they impact a lot more people. Pardon my spelling on this -- my spelling corrector seems to be malfunctioning. That's what I get for tinkering with it, I suppose..... -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
paulf@Umunhum.STANFORD.EDU (Paul A. Flaherty, N9FZX) (05/30/87)
In article <2445@pyramid.UUCP>, csg@pyramid.UUCP (Carl S. Gutekunst) writes: > In article <1685@Umunhum.STANFORD.EDU> paulf@Umunhum.STANFORD.EDU (Paul A. Flaherty, N9FZX) writes: > >Unfortunately, "--" results in a ^M being send down the line, which, true > >to the Hayes standard, hangs up the call. So, I was stuck, since I didn't > >have a true "null send". > Yes you do. Instead of: > >OK-AT^M-OK ATDT5551212 gin:--gin:-^M-gin: uucp > the correct form for v7 uucp is: > OK-AT\r\c-OK ATDT5551212 gin:-\c-gin:-\r\c-gin: uucp > \c means "don't send the default newline." And note that v7 ends each "send" > with a '\n' character (aka ^J), not a '\r' (aka ^M). > <csg> Yeah, that's what I thought, too. Unfortunately, placing \c in a send position causes "backslash cee" to be sent down the line. FYI, this is the binary only distribution of VenturCom Venix 1.1; which is much closer to V7 than SIII. But I can't imagine why they'd play with the V7 sources, which, for the most part, worked... At any rate, this is the last time I'll ever deal with a binary - only unix distribution...:-) -- Paul Flaherty, N9FZX >->-_->-> Computer Systems Lab -- Stanford University | Project ARPAnet: paulf@shasta.Stanford.EDU ===== OSCAR AMnet: N9FZX @ N6IIU =====