|
Problem in the base note was fixed by an MCC_DNA4_AM.EXE . This is documented in
a STARS article (see below). But where can I get the patched image ? Please
don't say from the CSC because I am from the CSC .
Thanks for any response.
Andrew
-----------------------------------------------------------------
[DECmcc]Problem trying to manage MAC PCs as NODE4 entities through DECmcc.
COPYRIGHT (c) 1988, 1993 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.
PROBLEM/SOLUTION ARTICLE OUTLINE
-------------------------------------------------------------------------------
PRODUCT: Polycenter Framework ( DECmcc Director ) V1.3
Polycenter Network Manager 200 ( DECmcc BMS ) V1.3
Polycenter Network Manager 400 ( DECmcc EMS ) V2.3
VMS 5.4-X, 5.5-X
Ultrix 4.X
DATE: 09-SEP-1993
SYMPTOMS/PROBLEM:
When trying to manage MACs through Node4 AM, response times are VERY long:
about 5 minutes to register a MAC and about 2 minutes to display any partition.
A command to display the same attributes under NCP, from the same station on
the same MAC takes about 5 seconds.
Note that a consequence is that most of the time, these MACs are not
discovered in a node4 autotopology process because of timeouts.
ANALYSIS:
The actual symtoms are :
1/ After typing a command as :
MCC>show node4 <MAC_NAME> all <partition>
wait about 10-15 seconds and then type CTRL-C : the result is immediately
displayed on the screen. And with correct values.
2/ After typing a command as :
MCC>show node4 <MAC_NAME> all <partition>
we can see that 2 links are created on the local station :
$ mc ncp show known link
Known Link Volatile Summary as of 27-APR-1993 14:10:58
Link Node PID Process Remote link Remote user
8251 62.176 (SFPC05) 0000005E SYSTEM 158 NML
8252 62.176 (SFPC05) 0000005E SYSTEM 0 NML
and one of them is always pointing to remote link 0. So again, wait about
10-15 seconds and disconnect the link pointing to the remote link 0 : the
result is immediately displayed. From this step, any show command issued on
this MAC will be immediately answered, even if tried HOURS later ( note that
only 1 link is now created, pointing to a non-zero remote link ) until exiting
from DECmcc.
Further analysis :
------------------
The reason for the long delay when sending management requests to
DECnet/Macintosh is because the AM is trying to determine if the node
can handle multiple links. Some DECnet implementations can service
several requests in parallel (VMS nodes for example), some routers
however, have only one management link so we have to treat them differently.
The access module makes the first connection, then tries to make a
second connection. Routers which can't handle it immediately reject the
request with a SS$_REMRSRC. That way the AM can tell that it is a "single
link" device. The Mac on the other hand is single tasking and doesn't
even see the second request. What happens is either the DECnet timer
eventually expires and the link fails, or a ^C aborts the attempt.
This is what is taking so long.
SOLUTION:
A new image MCC_DNA4_AM.EXE is available through CSC organizations. Two
modifications have been made :
If, the first time the AM tries to determine if the node supports multiple
links it gets a timeout, it assumes that it is a single link device and marks
it as such in the in-memory cache so that future requests don't try to make
the second connect. This means that there is still a lag, but only once.
After that the system knows it needs to make serial requests.
The second change is that a trace bit setting is added, which overrides this
checking scheme and treats *all* requests as single link requests. To use
this setting, define the following logical before running MCC :
$ define MCC_DNA4_AM_LOG 100
|