[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

569.0. "PDP-11 with Phase III DECnet ? " by BRUXL::LATOUCHE () Wed Dec 19 1990 08:53

Hello,

My question is not exactly the same as in 532 : There are customers that are
still running PDP's with DECnet *Phase III* in production.

I would imagine that we can perform some basic functions on those systems
thru the DECnet Phase IV AM. Does anybody have a practical experience 
(or a DECnet Phase III node I could test on ?)

Marc.
T.RTitleUserPersonal
Name
DateLines
569.1Yep, it work ! BRUXL::LATOUCHEWed Dec 19 1990 13:5641
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.2Not quiteNAC::SCHLENERWed Dec 19 1990 19:1217
    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.3So, will the Phase IV AM be able to talk to a Phase III system. ?VIDOAN::DOANEIS/Network Consulting Group of the 90'sThu Dec 20 1990 13:0214
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.4Anyone have MCC same area as Phase III node?TOOK::CAREYThu Dec 20 1990 14:3737
    
    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.5MCC thinks Phase III = Cluster AliasSUBURB::SMYTHIIan Smyth 830-3869Fri Dec 21 1990 14:5854
	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.6alittle info on cluster aliasesNAC::SCHLENERFri Dec 21 1990 17:5517
    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.7try a show insteadGOSTE::CALLANDERFri Dec 21 1990 18:174
    
    Try it again, if you can, without registering it. Simply try
    to do a show on it and see what happens.
    
569.8Still checking for AliasSUBURB::SMYTHIIan Smyth 830-3869Sat Dec 22 1990 10:0725
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.9Try specifying by address....TOOK::CAREYWed Jan 02 1991 13:0444
    
    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.10Addresses don't work either.SUBURB::SMYTHIIan Smyth 830-3869Mon Jan 07 1991 15:0121

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.11IPhase IV is compatable w/ Phase IIICAPN::SYLORArchitect = Buzzword GeneratorTue Jan 08 1991 19:323
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.12Compatable, but the AM rejects it (accidentally)TOOK::CAREYWed Jan 09 1991 12:4420
    
    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