Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!public!thad From: thad@public.BTR.COM (Thaddeus P. Floryan) Newsgroups: comp.sys.3b1 Subject: Re: Seeking modem pinouts (3b1) Keywords: 3b1 modem DCD CD DTR HDB UUCP Pcomm Kermit Message-ID: <1855@public.BTR.COM> Date: 21 Feb 91 07:47:40 GMT References: <1991Feb13.172049.21792@progress.com> <1991Feb17.174820.18716@blilly.UUCP> <1840@public.BTR.COM> <1991Feb20.023929.24345@blilly.UUCP> Followup-To: comp.sys.3b1 Organization: BTR Public Access UNIX, MtnView CA, Contact: cs@btr.com 415-966-1429 Lines: 118 bruce@balilly.UUCP (Bruce Lilly) in <1991Feb20.023929.24345@blilly.UUCP> writes: Unless CD is asserted, a write to/read from a tty port will fail. So something like: echo ATZ >/dev/tty001 will not work, if a modem connected to the port has not asserted CD. The connection I gave will work, as DTR is asserted when the port is open(2)'ed. Oh? Then perhaps you'd like to explain why HDB UUCP, Kermit, Pcomm, etc. all can "talk" to a modem whose CD signal is not asserted TRUE at the 3B1's RS-232 interface port? Has everyone so quickly forgotten the anecdote posted last month about a person who called the US Naval Observatory time service number in Washington, DC, only to later find a humongous phone bill because the modem wasn't strapped to properly drop CD when the connection was to be terminated? Seems people have forgotten my posting two years ago when I brought up HDB UUCP on my 3B1 and I claimed that HDB was brain-damaged and "... would put even Mother Theresa on a killing rampage...". The docs for HDB UUCP in this regards are truly bad for the "stock" SVR3.2 version (but are OK in the docs for the 386 SVR3.2 manual set). Some of the docs do appears in the SVR3.2 Utilities Release Notes in obscure places. Remember: the "stock" version 2 uucp worked correctly talking to a modem when CD wasn't asserted, but the HDB did NOT work correctly until one used the very poorly documented "\M" (for CLOCAL) in Dialers and ",M" in Devices. Nothing in any of the HDB UUCP files will affect the example given above. I've been using the connection above with no problems whatsoever. I just one paragraph above mentioned the "\M" and the ",M" ... those options ONLY work for HDB and for precisely the reasons I've described time and time again. Thad, why do you feel that ``it is MOST important for the 3B1...''? 1) What will break given the connection I posted? 2) How would you be able to write to the modem (simply) from the shell? 1) If some data connection terminates abnormally (i.e. without the "OO" from uucico), your line may stay connected forever. Not good for one's pocketbook on a long-distance call. One should ALWAYS respect the condition of DCD & DTR for unattended (i.e. automatic) modem usage. 2) I would never care, under normal circumstances, to write to the modem direct from the shell, but when I do, I would simply do: ls -l /dev/tty* and for each ttyXXX's [major,minor] pair, simply do: mknod modemXXX c major (minor+128) and then you can do what you wanted to do, WITHOUT the (improper) need to continuously assert CD from the modem. In case this isn't clear: $ ls -l /dev/tty0* /dev/modem* crw-r--r-- 1 root root 0,128 Feb 20 19:49 /dev/modem000 crw-r--r-- 1 root root 0,130 Aug 25 15:26 /dev/modem001 crw-r--r-- 1 root root 0,131 Aug 25 15:26 /dev/modem002 crw-r--r-- 1 root root 0,132 Aug 25 15:26 /dev/modem003 crw-r--r-- 1 root root 0,133 Feb 16 06:59 /dev/modem004 crw-r--r-- 1 root root 0,134 Aug 25 15:27 /dev/modem005 crw-r--r-- 1 root root 0,135 Aug 25 15:27 /dev/modem006 crw-rw-rw- 1 uucp users 0, 0 Feb 20 19:48 /dev/tty000 crw-rw-rw- 1 uucp users 0, 2 May 13 1990 /dev/tty001 crw-rw-rw- 1 uucp public 0, 3 Jan 7 1990 /dev/tty002 crw-rw-rw- 1 uucp users 0, 4 Feb 20 14:22 /dev/tty003 crw-rw-rw- 1 uucp users 0, 5 Feb 16 06:59 /dev/tty004 crw-rw-rw- 1 root users 0, 6 Mar 2 1988 /dev/tty005 crw-rw-rw- 1 root users 0, 7 Mar 2 1988 /dev/tty006 I exploit that capability in my highly-modified version of Boyd Ostroff's "modemon" package for the 3B1. Hmmmm, perhaps I should email that stuff to Dave for posting to comp.sources.3b1 since it easily solves EVERYONE's modem and uucp problems. Having created such "modemXXX" devices permits handling them from the shell or other programs as do the "\M" and ",M" for HDB UUCP. All this can be summed up as: ********************************************************************** * The correct assertion of a CD signal from the modem to a DTE (i.e. * * a 3B1) is as important as is a DTR signal from a DTE to a modem. * ********************************************************************** Bruce continues: Sidebar: many modems have a hardware (and possibly software) option to continuously assert CD so that writing to the modem is possible when carrier is not present (e.g. refer to page 2-4 of the Digicom Systems, Inc. 9624LE User's Manual). I have 2 of those modems (and their manuals); the page is "1-4" in the Digicom 9624LE manual, and the description is either: "DCD Forced on" OR "DCD normal RS-232" The "normal" state of DCD is for the signal to be asserted true ONLY when there is a data carrier detected (DCD) (i.e. one's modem is talking to another). I hope everyone can convince Bruce to pay your phone bills for "terminated" but still live phone calls if you take his advice in this regards! :-) And please note I'm NOT trying to impugn Bruce. Modem problems are a common question thread I handle at user and technical meetings. Most modem manuals would have been better never written due to how much they confuse the issues, and I have yet, after 25+ years, to find a "good" modem manual. Thad "Mr. Modem" Floryan [thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad] Brought to you by Super Global Mega Corp .com