modems under delay not dropping DTR on 3003
Robin
Robin
Tue Jun 18 00:22:05 AEST 1991
In article <7868 at spdcc.SPDCC.COM> rbraun at spdcc.COM (Rich Braun) writes:
> pensoft!robin writes:
> This is getting tedious; I don't really like the tone of your entire posting.
Frankly Rich, I don't care if you like the tone of my postings or not... I am
not here as an official IBM representative, and I am not bound by any
constraints to make any one person (or many people) happy here. I am
responding to requests that I might have a little more inside knowledge on
simply because I used to work with the group of people who actually did know
what was going on with this system... You will note that I don't post responses
to articles that I know nothing about, and I try not to get too snotty with
people, simply because that's the way I AM... On the other hand, never bite
the hand that feeds you.
> Believe me, my system *does not work* even after looking at the guide
> you so graciously provided and at the documentation provided by IBM.
> The terminal line has 'hupcl' set and clocal not set. The patch (IX11286)
> is *clearly marked* by IBM as "for 3005 systems", and I am running 3005.
> There is one inconsistency, though: it also says "64-port fix" and I have
> an 8-port card.
It is possible I am wrong about the IX11286, if so I am sorry about mis-leading
you. On the other hand, let me call my friends at level 2.... (I am calling
right now).... (5 minute delay in this posting was caused by various
discussions with a friend (including the fix level of IX11286)). I stand
corrected (partially), the fix for IX11286 is in the 2006 update. Also, as
Rich noted the IX11286 fix is for the 64port adapter card, and should not
affect the 8 port card.
> >As far a "DELAY" not being used for dial-ups, please stop spreading this
nasty
> >rumor. "DELAY" works fine with both dial-up and direct connect.
>
> You should state this more clearly in the guide you put out; the way I
> interpreted it, the 'getty' program will do the wrong thing by locking
> the port if 'delay' is set and a character is received. *Most* modems
> these days will send characters at numerous points when carrier detect
> is not present. This needs to be spelled out in any documentation on
> the subject. Your document clearly implies that getty ignores carrier
> detect in making the decision to lock the port, if 'delay' is selected.
That is not what the guide says. Allow me to quote:
DELAY: This setting is nearly identical to the "SHARE" setting, except
the getty is called as: "getty -r" (which is the same as the AT&T
uugetty -r) and this version of getty is waiting to see a character
on the serial input buffer (read() on the tty doesn't return '0').
before it attempts to lock the port. So in the paragraph above, just
replace all occurances of "CD" and "Carrier" with "Character on the
serial input buffer".
NOTE: the text says "...to lock the port." I never said, DELAY ignores
carrier, or carrier is irrelavent to delay. In fact, carrier is always
relavent on the serial port driver. If carrier is not high, the serial port
driver does not read (OR WRITE) characters from/to the serial port. Unless
the "CLOCAL" bit is set. When the modem is writing to the serial port, BEFORE
carrier is high, those characters are buffered by some modems, and presented
after carrier is high, and on other modems they are just discarded. STILL,
some modems do like to talk to the serial port, before, during and after the
conneciton is being established. They say things like "RING", and "CONNECT",
and the serial port interprets these things as attempted logins. The way to
solve this is to setup the modem correctly. (I believe if you read the rest of
the guide you will find the string:
Command Response should be set to respond to "LOCAL" commands only.
In the text that follows, (a complete paragraph) I attempt (possibly this part
is not well written) to describe why this is neccessary. Even so, I believe
that this is needed on ANY VENDOR's system to prevent invalid LOGINS. Even on
out old VAX 8650 (running VMS) this was a neccessary setting to prevent the
modems from registering an invalid login.
> >You call 1-800-237-5511. I think you are wasting your time, this is not a
> >software defect. Sorry.
>
> It need not be a software defect in order to be a major hassle for me.
> There are numerous line-control parameters which may not be set correctly,
> and I have yet to learn any means of fixing the problem. Therefore there
> *is* a problem with the software, the documentation, or (more likely) both.
I disagree. The documentation is intended as a reference for users, and System
Admins. It is not a text book with all you need to know about every part of
the system. Given that many people seem to have the same problems with ttys
that I had when I started learning about them, I wrote a "beginners" book on
getting modems set up. But this is not to be mis-construed as an IBM book, or
official IBM documentation. It is MY OPINION ONLY!
The fact that you are having a problem understanding how to get this particular
task done, does not make it a software DEFECT. Instead, you should take this
up with an SE, or a marketing rep.
> Please understand my point of view.
Try to understand, this flame is not a result on not wanting to help. I am
merely responding to the idea that I am here to serve you (or anyone on the
net). I am here to serve my own special interests, and nothing else. I answer
questions because I think (please note that even though I sometimes write using
the tone: "I do know what I am talking about" -- it is ALL my OPINION, and I
"at most" can only provide what I "THINK") I know the answer; nothing else.
--
+-----------------------------------------------------------------------------+
|The views expressed herein, are the sole responsibility of the typist at hand|
+-----------------------------------------------------------------------------+
|UUCP: pensoft!robin |
|USNail: 701 Canyon Bend Dr. |
| Pflugerville, TX 78660 |
| Home: (512)251-6889 Work: (512)343-1111 |
+-----------------------------------------------------------------------------+
More information about the Comp.unix.aix
mailing list