| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1455.1 | Somemore clues | CHOWDA::GLICKMAN | writing from Newport,RI | Tue Dec 24 1996 13:47 | 31 |
| A couple of more clues I want to include:
PCM 1.6-201
This is to a VAX 7000 740 with a modular cable.
Connections to 2 8820s (25 pin connection) and a DEC 3000 (modular
but different than the VAX 7000) work fine.
The DECserver port configuration looks like this for all the ports:
Character size: 8 Input Speed: 9600
Flow Control: XON Output Speed: 9600
Parity: None Modem Control: Disabled
Stop Bits: Dynamic
Access: Remote Local Switch: None
Backwards Switch: None Name: PORT_4
Break: Remote Session Limit: 4
Forwards Switch: None Type: Ansi
Default Protocol: LAT Default Menu: None
Dialer Script: None
Preferred Service: None
Authorized Groups: 0
(Current) Groups: 0
Enabled Characteristics:
Failover, Input Flow Control, Lock, Loss Notification, Message Codes,
Output Flow Constrol, Verification
|
| 1455.2 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Tue Dec 24 1996 14:12 | 44 |
| I see this problem from time to time. Since you can actually connect to
the SYSTEM via CONSOLE CONNECT the LAT connection is okay so leave
that alone. Since you can see Opcom messages then at least one way
communication is working. There are several things to check:
Unplug the deccconect cable from the managed systems console and
plug it back into a VT terminal. Make sure the communcations settings
are correct on the terminal. Now CONNECT to the managed system
via a CONSOLE CONNECT command and when the connect is made type some
characters. Check the VT terminal screen to see if those characters
appeared. Now type some characters on VT terminal and check the
CONSOLE CONNECT "window" to see if those characters appeared. If
both of the above tests work then the cable and terminal server port
are okay. If one of the tests does not work do the following:
1. Replace the decconnect cable and repeat the two tests.
2. connect to the DECServer's console and do SHOW PORT x STATUS
see if Input or Output is Xoff'd. Note that "x" is the number of
port that the managed system is connected to. If either input or
output is xoff'd logout the port via
Local> LOGOUT PORT x
PCM will lose the connection to the server port and reconnect to
it within 120 seconds. These events will be noted in the
Multi-Line Window. Once the reconnection is made repeat the
"character typing" tests in both the PCM CONNECT session and
at the VT terminal. If everything works, plug the cable back into
the managed system.
If you still can't communicate with the managed system then
it's console port is hung. Login to the managed system and do
$ANAL/SYSTEM
SDA> SHO DEVICE OPA0:
and post the results. I would expect you'll find a device status
value of 90 or 92 hex. You can reset this value with the system
level debugger but it's risky. The best thing to do is shutdown
and power cycle the system when convenient.
Regs,
Dan
|
| 1455.3 | Another test... | CRLRFR::BLUNT | | Tue Dec 31 1996 07:59 | 55 |
|
If the port is hung on the managed system, then you can check in the
notesfile pertinent to that system to see if it's a known problem.
Also, I usually connect the console cable from the system to a terminal
to verify the cable as well (sort of the reverse of what Dan suggested).
If you can login, then it's not the console that's hung. You might
check to see if the terminal has been set nobroadcast and do a
$ REPLY/STATUS to verify that the console is still enabled as an operator
(you should still get some messages, tho).
Dan's test will also check the DECserver port to validate that it is
operating properly. While this isn't extremely common, it does happen.
You mentioned that your 3000 systems were using different modular
connections. Were you referring to just more/different adapters
involved, different vendors for the modular gear or what?
One of the things that has changed from VCS to PCM is that there
appears to be much less checking of the physical connection from the
"managing port (DECServer or direct)" to the "managed system." If the
connection can be made using LAT to the DECserver, that system will
"come up" under PCM. Under VCS, unless certain signals were present
from the DECserver port to the managed host, it wouldn't come up
(MANY sleepless hours spent on this one). It's a double-edged sword
in that it's a piece of cake to setup PCM (in comparison), but there
seem to be more places where something simple can cause a real problem.
The additional "monitoring" in VCS wouldn't solve a console hang issue,
as the signals would still be there and the console would still be
hung...
Dan didn't mention any issues with the port setup, but here's how we
have our DS700-16s configured (there will be some differences):
Port 1: (Remote) Server: DSV701
Character Size: 8 Input Speed: 9600
Flow Control: XON Output Speed: 9600
Parity: None Signal Control: Disabled
Stop Bits: Dynamic Signal Select: CTS-DSR-RTS-DTR
Access: Remote Local Switch: None
Backwards Switch: None Name: TLASER
Break: Remote Session Limit: 1
Forwards Switch: None Type: Ansi
Default Protocol: LAT Default Menu: None
Preferred Service: None
Authorized Groups: 0
(Current) Groups: 0
Enabled Characteristics:
Input Flow Control, Output Flow Control
bob
|
| 1455.4 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Tue Dec 31 1996 14:19 | 39 |
| > One of the things that has changed from VCS to PCM is that there
> appears to be much less checking of the physical connection from the
> "managing port (DECServer or direct)" to the "managed system." If the
> connection can be made using LAT to the DECserver, that system will
> "come up" under PCM.
Actually there is not that much difference. Both VCS and PCM check the
status of all QIO's via the IOSB. If the connection drops then the
IOSB will contain a data-set hangup error code. When this occurs on
VCS an extra QIO is sent to the tell the LTdriver to cleanup. When this
happens on PCM the LTA port is actually foramlly disconnected and
deleted. Every 150 seconds a timer fires and checks for lines that need
to be reopened and does do. In the case of a LAT connection, a new LTA
device is created and mapped to the target server and port and a
connection is initiated.
> Under VCS, unless certain signals were present
> from the DECserver port to the managed host, it wouldn't come up
> (MANY sleepless hours spent on this one). It's a double-edged sword
> in that it's a piece of cake to setup PCM (in comparison), but there
> seem to be more places where something simple can cause a real problem.
> The additional "monitoring" in VCS wouldn't solve a console hang issue,
> as the signals would still be there and the console would still be
> hung...
Quite honestly this is a function of the decserver. VCS never did any
signal checking in it's QIO's so it never had the intelligence to know
if a signal was present or not not did it care. I have always used the SET HOS/DTE
command to check connections to server ports. If it works then PCM
or VCS should successfully connect to the server port. There's no
question that if the server port is enabled for signal check that
things will behave as you describe if things aren't hunky-dorey with
signalling. I believe the VCS installation guide specially recommended
that signal-check and signal control be turned off. Some customers used
it so the connection would drop if someone unplugged the cable or it go
yanked out accidentally.
Regs,
Dan
|
| 1455.5 | No disagreement here... | CRLRFR::BLUNT | | Tue Jan 07 1997 10:59 | 10 |
|
Mostly, WRT VCS, I never could get the initial connection if the any
of the giblets were NOT just perfect. Yes, O.K., many times it was
one of the VCS$LTA command procedures (but I've had the *joy* of
debugging both LAT group misalignments and no node name on the DSV).
Sometimes, I was still able to $SET HOST/DTE and get what seemed to be
a good, but nonresponsive, connect. However, I will not disagree, it
is a "tool" that I'd be hard-pressed to get this stuff working without.
bob
|