As a general case, yes, Jim Rees is right - you can't assume
an unterminated rs-232 line will do anything special.
However, as a practical consideration, you can expect that
if there is a volt or 2 of "noise" on the rs-232 line,
it won't be significant. It's digital logic, after all.
If it were significant, and it occured at any speed, it
would certainly result in a serious degradation of system
performance. For carrier detect, a high frequency noise could
result in the generation of thousands of interrupts a second,
which could swamp either an I/O processor, or the CPU.
The console ports on an RS/6K are (I believe) driven by
the CPU. A lower frequency noise could result in
spawning & killing a "getty" many times a second,
which can result in even more drammatic effects
on system load & performance. A sick modem will occasionally
generate this kind of behavior. But as a general rule,
you can expect that at the very least, there will be
appropriate filtering and/or high resistant pullups or pulldowns
or something, so that unterminated lines will go to one state or
the other and stay there.
Which state they go to isn't specified, which is the real reason
it's not predictable. Most older equipment tends to go to a '0'.
Somewhere in there, some bright person figured out how
to make cable making easier, so some newer equipment
goes to '1' instead. That's probaby especially likely for
CTS/RTS. For DTR & other lines, it's often a '0', so that
the lack of a terminal can be detected.
'0' is in fact the case for carrier detect on the RS/6K - if the kernel
debugger is enabled, the first serial line of S1,S2 that supplies carrier
detect will become the console - it will receive any kernel debugging
messages, and if the key is in the service position, a control-backslash
on the console will trap into the debugger.
-Marcus Watts
UM ITD RS Umich Systems Group
