| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 569.1 | Yep, it work !
| BRUXL::LATOUCHE | | Wed Dec 19 1990 10:56 | 41 |
|
To keep you informed : Thanks to Henk Witmond, I found a DECnet Phase III node
on EASYnet (in Holland).
Node 50.155 runs DECnet Phase IV and 50.181 runs DECnet Phase III :
MCC> show node4 50.155 remote node 50.181 all attributes
Node4 50.155 Remote Node 50.181
AT 19-DEC-1990 16:30:19 All Attributes
Address = 50.181
Name = UTR11B
Circuit = DMC-0
Cost = 10
Hops = 1
Next Node Address = 0.181
Next Node Name = UTR11B State = Reachable
Connects Received = 0 Connects
Connects Sent = 1 Connects
Counter Creation Time = 19-DEC-1990 12:26:04.82
Received Connect Resource Errors = 0
Response Timeouts = 0 Timeouts
Seconds Since Last Zeroed = 14678 Seconds
Total Messages Received = 6 Messages
Total Messages Sent = 5 Messages
User Bytes Received = 203 Bytes
User Bytes Sent = 8 Bytes
Node could not open required file: Permanent Database.
File = Permanent Database,
System Error Message = "%NML-E-OPENIN, error opening
SYS$COMMON:[SYSEXE]NETNODE_LOCAL.DAT;
as input
-RMS-E-FNF, file not found"
So, it works using PHASE IV AM . (I tried also SHOW ... ALL STATUS, ALL COUNTER)
This is superbe !
Marc.
|
| 569.2 | Not quite | NAC::SCHLENER | | Wed Dec 19 1990 16:12 | 17 |
| re -.1
I hate to tell you but you never did communicate with the phase III
node according to your MCC syntax. The node4 entity designates what
you want your "exec" to be. It works like the TELL command in NCP.
The Phase IV AM will issue a decnet connect to the node specified as
the node4 entity. So if you did a MCC> SHOW NODE4 FOOBAR ALL CHAR and
you were on node BENCH, that command is equivalent to
NCP> TELL FOOBAR SHOW EXEC CHAR.
According to your MCC command syntax, you asked a Phase IV node it's
"view" of a phase III node (just like the NCP node entity). In order to
actually TALK to a phase III node, you would have to issue the
following command
MCC> SHOW NODE4 phaseIII node-id ALL CHARACTERISTICS
Cindy
|
| 569.3 | So, will the Phase IV AM be able to talk to a Phase III system. ? | VIDOAN::DOAN | EIS/Network Consulting Group of the 90's | Thu Dec 20 1990 10:02 | 14 |
| Hi,
Re:.2
So, can Phase IV AM communicate with a Phase III node ? or NOT ?
Thanks
Thien Doan
EIS/Network Consulting Group
PS: Marc, great to see you testing this product.
|
| 569.4 | Anyone have MCC same area as Phase III node? | TOOK::CAREY | | Thu Dec 20 1990 11:37 | 37 |
|
Any volunteers in area 50 to install MCC and check it out?
Phase III nodes don't talk out of area. So, when I tried to tickle it
directly with MCC from here (area 4) I didn't get anywhere.
I dredged back in my memory, and talked to a couple of other people
old enough to have worked on the Phase 3 to Phase 4 migration (and we
thought that was hard!). Here is what we remember:
o Phase 3 nodes don't know about Areas. The local Phase IV router
takes care of that for it. So they can't talk out of area, and
if we want to try MCC on it, we'll have to get an MCC into an
area with a Phase 3 node.
o Phase 3 nodes must be an address under 255 to work on Phase 4.
o There was some funny handshake with receive and transmit
passwords, but it was just an Easynet convention.
o Finally (the best part), we can't remember any major changes to
the NICE protocol. It was extended to manage multiple areas, and
Ethernet circuits, but as near as any of us can remember, the
Phase 3 attributes still manage just as they did in Phase 3.
That means that it's likely that we can talk to Phase 3 nodes, but
there's no way for us to check it out here.
Anyone have a Phase 3 node in their area and willing to bounce some
MCC commands off of it? Anyone willing to install an MCC field test kit
in an area with a Phase 3 node to try it?
If there is a problem, we may never have a chance to get back to fix
it, but it would be nice to know.
-Jim Carey
|
| 569.5 | MCC thinks Phase III = Cluster Alias | SUBURB::SMYTHI | Ian Smyth 830-3869 | Fri Dec 21 1990 11:58 | 54 |
| I tried this on one of the few remaining Phase III RSTS
systems in the UK.
RDGEMA::SYSTEM >Mc ncp tell rdge02 sho exec char
Node Volatile Characteristics as of 21-DEC-1990 16:45:06
Executor node = 242 (RDGE02)
State = on
Identification =
Management version = V3.0.0
Loop count = 1
Loop length = 128
Loop Data type = mixed
Counter timer = 0
Incoming timer = 120
Outgoing timer = 120
NSP version = V3.2.0
Maximum links = 32
Delay factor = 48
Delay weight = 3
Inactivity timer = 120
Retransmit factor = 5
Routing version = V1.3.0
Type = nonrouting III
Routing timer = 120
Maximum address = 255
Maximum circuits = 1
Maximum cost = 1022
Maximum hops = 10
Maximum visits = 20
Maximum buffers = 75
Buffer size = 576
Parameter #2124 = U2
Parameter #2125 = [11,116]
Parameter #2126 = 4
Parameter #2127 = 2
Parameter #2128 = SY0:[0,1]NSP0.SYS
RDGEMA::SYSTEM >manag/enter
DECmcc (T1.1.0)
MCC> register node4 .dna_node.rdge02 syn=rdge02
Node4 RDGEMA_NS:.dna_node.rdge02
AT 21-DEC-1990 16:42:11
The requested operation cannot be completed
MCC Unhandled Service Reply = Specified Node4 is a Cluster Alias.
Use a cluster member.
A cluster member = 0.242
MCC>
|
| 569.6 | alittle info on cluster aliases | NAC::SCHLENER | | Fri Dec 21 1990 14:55 | 17 |
| This is probably due to the Phase IV AM code not finding the alias node
characteristic which (prior to my leaving the group) was going to be
the deciding factor to determine if the node name was solely a cluster
alias. It's possible that the algorithm didn't take into effect not
finding that characteristic.
NCP and MCC had the problem of allowing attribute modifications when
the "executor"/NODE4 was really a cluster alias. Hence, the user was
never certain which node was affected. This was to be fixed in the
Phase IV AM by trying to keep a list of cluster aliases (or something
like that) and preventing modifications when using any of them.
Hence by trying to register the node via MCC, evidently a check is done
in the AM not allowing registration of cluster aliases.
Cindy
|
| 569.7 | try a show instead | GOSTE::CALLANDER | | Fri Dec 21 1990 15:17 | 4 |
|
Try it again, if you can, without registering it. Simply try
to do a show on it and see what happens.
|
| 569.8 | Still checking for Alias | SUBURB::SMYTHI | Ian Smyth 830-3869 | Sat Dec 22 1990 07:07 | 25 |
|
Here is the result of a few "Show Node4 RDGE02 all xxxxx, to file=x"
Node4 rdge02
AT 22-DEC-1990 11:54:44 All Attributes
Specified Node4 is a Cluster Alias. Use a cluster member.
A cluster member = 0.242
Node4 rdge02
AT 22-DEC-1990 11:55:25 Identifiers
Specified Node4 is a Cluster Alias. Use a cluster member.
A cluster member = 0.242
Node4 rdge02
AT 22-DEC-1990 11:55:11 Status
Specified Node4 is a Cluster Alias. Use a cluster member.
A cluster member = 0.242
|
| 569.9 | Try specifying by address.... | TOOK::CAREY | | Wed Jan 02 1991 10:04 | 44 |
|
Cindy, you were on the right track on this one.
We did implement some cluster alias checking for V1.1 of DECmcc.
It allows FMs to be sure they are working in a consistent environment,
and will push back on the user to ensure that they are working with a
single node, instead of modifying or monitoring the status of one of a
group of nodes.
The check is very simple:
o We translate the node name into an address inside the AM
o We request identifiers from the node at that address.
o If the address that we get in the response is different from
the address to which we made the request, we conclude that a
cluster member responded to a request made to a Cluster Alias,
and we fail the request with the exception that you have
encountered.
The same thing happens with a Phase III node because there is no Area
component on the address. That is, the address compare fails, and we
conclude that the node is a cluster member.
Try making the request as:
SHOW NODE4 242 ALL CHAR
or
SHOW NODE4 0.242 ALL CHAR
One of those may get through our checking, and allow the request to
complete.
Fixing our cluster check should be straightforward as well, but at this
late date, it won't make it into V1.1. We'll see what we can do in the
future.
Let me know if either of these schemes works. This is a fun function
to support, so I'd like to know that we manage somehow.
-Jim Carey
|
| 569.10 | Addresses don't work either. | SUBURB::SMYTHI | Ian Smyth 830-3869 | Mon Jan 07 1991 12:01 | 21 |
|
RDGEMA::SYSTEM >manage/enter
DECmcc (T1.1.0)
MCC> show node4 242 all char
Node4 242
AT 7-JAN-1991 16:52:38 Characteristics
Specified Node4 is a Cluster Alias. Use a cluster member.
A cluster member = 0.242
MCC>
MCC> show node4 0.242 all char
Node4 RDGEMA_NS:.0.242
AT 7-JAN-1991 16:53:07 Characteristics
Node is not registered.
MCC> exit
|
| 569.11 | IPhase IV is compatable w/ Phase III | CAPN::SYLOR | Architect = Buzzword Generator | Tue Jan 08 1991 16:32 | 3 |
| For what it's worth, Phase III NICE is compatabile with Phase IV. It's a
pure subset. If you are in the same area as the node, the Phase IV AM
should be able to manage.
|
| 569.12 | Compatable, but the AM rejects it (accidentally) | TOOK::CAREY | | Wed Jan 09 1991 09:44 | 20 |
|
re: .11
I agree that it should be able to manage. This case, however, looks
just like the case of a request being made to a Cluster Alias (the
response contains a different address than the request was made to).
We reject it (right now) for consistency's sake.
So, as it stands for V1.1 of DECmcc, it is likely that the DECnet Phase
IV AM will continue to reject attempts to manage the Phase III node
directly. It looks like a simple fix, and there's a good chance it
will creep into the AM sometime in the near future. Until then, if you
are managing Phase III nodes, the best you can do with DECmcc is
monitor reachability and "Remote Node" characteristics for it via a
nearby router. This at least allows you to know about its status on
the network using DECmcc, although you will not be able to control it
directly, or Register it in the Instance Repository.
-Jim Carey
|