Conference azur::mcc

I got the following error (and have been getting this error for a while) while
    trying to register a node.
    
    Of course, MCC communicates with DNS just fine to delete the parts of
    the registeration that already were created.
    
    
register node4 .DNA_Node.BBZK99 syn BBZK99
Node4 2.3 Circuit SYN-1
AT 13-SEP-1990 16:48:20


The requested operation cannot be completed
                      MCC Routine Error = %DNS-E-NOCOMMUNICATION, Unable to
                                          communicate with DNS server

I got the following for the first time, ever.  Any idea what this means?
    
    
register node4 .DNA_Node.MARVIN syn MARVIN
Node4 1.56
AT 13-SEP-1990 16:56:06


The requested operation cannot be completed

%MCC-E-NOENTITY,  no corresponding entity instance exists
    
    
    Configuration:
    
    	VMS V5.4-4G1
    	DNS running on the SAME system
    	No duplicates of and DNS directories
    	Etc......

I thought this was supposed to be fixed?
    
    
    
register node4 .DNA_Node.BOOTIT syn BOOTIT
Node4 DAVE:.DNA_Node.BOOTIT
AT 13-SEP-1990 16:51:41


The requested operation cannot be completed
                      MCC Service Error = Internal error in DECnet Phase IV AM.

The following errors (and text) is from the MCC_SETUP_DNS command file on the
NEW (12-SEP-1990) BMS kit.

    I ran the above command file to create all the DNA_* directories after
    installing DNS (and before running MCC).  When I went to exit, I got
    the following error messages. 

-----------------------------------------------------------------------------
     .
     .
     .
Qualifiers appearing before this item were ignored
 \SYMBOL\
Qualifiers appearing before this item were ignored
 \SYMBOL\
Qualifiers appearing before this item were ignored
 \SYMBOL\
Qualifiers appearing before this item were ignored
 \SYMBOL\
Qualifiers appearing before this item were ignored
 \SYMBOL\
Qualifiers appearing before this item were ignored
 \SYMBOL\
Qualifiers appearing before this item were ignored
 \SYMBOL\
Qualifiers appearing before this item were ignored
 \SYMBOL\
File not found
Invalid internal stream identifier (ISI) value
$
                                 

REGISTER NODE4 still appears to have memory leaks under certain (unknown)
conditions.

Another register error:

register node4 .DNA_Node.LAVC02 syn LAVC02
Node4 1.732 
AT 13-SEP-1990 18:11:07


The requested operation cannot be completed
                      MCC Routine Error = %MCC-E-DUP_IDENTIFIER, duplicate 
                                          identifier encountered during 
                                          registration
register node4 .DNA_Node.LAVC03 syn LAVC03
Node4 1.733 
AT 13-SEP-1990 18:11:35


Registration Successful

    Dave,
    
    The SSB kit has not been announced outside of MCC yet, although I did
    send mail to the V1.0 Project Leaders.  We have decided NOT to make the
    kit available on KEEL until we've had a chance to check out the DNS
    problems more thoroughly.  Putting it on KEEL lead some to believe it
    could be passed out to people outside the MCC community, a bad call on
    my part.
    
    Also, you're right.  The DNS problems were supposed to be fixed for the
    SSB kit.  In fact, after the changes were tested, I code reviewed all
    changes and made sure they went into the SSB CMS class personally.  So
    I'm as concerned as anyone about these problems.
    
    Thanks for the work you've put in, Dave.  It is very much appreciated!
    
    -Matt.

    Dave,
    
    
    ref .1:
    
       The error message "Unable top communicate with DNS server" occurs
    when MCC is trying to read or write onto the DNS data base.
    
       The node4 registration works as follows:
            - It creates the global entity in DNS data base
    	    - It writes all other MCC realted attributes
            - It creates Synonym
    	    - It adds the Back translation
            - It adds MCC_UID link
            - Then adds  the relevant SUBENTITIES 
    
      To do each of these, MCC accesses the name server. It is possible
    that the name server is busy and the client may time out in doing any
    of the above. That is the error message  you are seeing.
    
      A solution to this problem is to place a wait loop (say 1 sec at a time,
    for maximum of 5 sec) whenever this error occured.  We have discussed
    this solution in our group, and we are planning  to include it in V1.1.
    	
    
    
    ref .2:
    
        The error MCC_S_NOENTITY encodes a lot of possible errors.
        (More meaningful error messages in future.)
    
        One of the possiblities is that the node MARVIN is not responding
    to the Phase IV AMs SHOW commands. So when this error occurs, try doing
    some SHOW commands on the node which is to be registered. Most often
    this will reveal the problems.
    
    
    ref .3:
    
       The Phase IV AM internal error message is a known bug.
    DECmcc V1.0 release notes contains  a note on this bug.
     
    We could not reproduce it so far.  My strong feeling is that the PHASE IV
    AM is taking the "blame" of saying its own internal error, when its 
    interface to DNS fails for some reason. We are planning to track this 
    problem down and will be in  V1.1.
      
    
    ref. 4:
    
       Yup !!! looks like there is a bug in the COM procedure. We are
    looking it. Thanks a lot for pointing it out. It is possible that you are
    using a symbol that we are also using in the COM file. I think Larry
    Grossman already talked to you about this.
    
    
    
    
    
    ref .5:
    
          We are aware of the existence of memory leaks. But we have no
    information on the size of the leak. Unless it is significant and 
    reproducable, there is not worth looking at  it in V1.0.
    
         Can you give us some data about the size of the leak???
    
    ref .6:
    
         This error message (Duplicate identifier) occurs when MCC adds a
    back translation or a synonym link. If the link to be added already,
    exists, then MCC checks whether it point to the same global entity object
    that is being registered. If it does not point the same object, this
    error occurs. 
    
         To trouble shot this problem, first check the DNS$LINKTARGET
    pointed the backtranslation link, and then by the synonym link. 
    
         If you still have a problem, I will be glad to look further into
    it.
    
    
    
    Finally,
    
       Dave, thanks a lot for this feedback. It is nice to have some one
    next door who can  test  the product right away. Keep us posted....
    
    
    ... Jay
    

The error in 325.4 may be due to the symbol DELETE being defined to be DELETE/LOG.
I believe that the mcc_setup_dns routine does a DELETE/SYMBOL which with the DELETE
symbol being defined above yield DELETE/LOG/SYMBOL wich is an illegal combination.
The mcc_startup_*.com procedures had this problem when they incorporated some stuff
from other MCC_*_DNS.COM procedures, and fixed the problem  See the kitinstal for
the fix.


regards

\steve

    The VMS group got burned by the SYMBOL stuff on several of their own
    installs back in VMS V3 days. They since changed their practice to make
    sure that ALL Verbs used in command proceedures were redefined back to
    the default state in the initiallation of the comm proceedure.
    
    for example
    
    $ DIRECTORY := DIRECTORY
    $ SHOW      := SHOW
    
    s/rob

    When I installed the kit I foundthe following:
    
    The Installation procedure displays the following;
    -------------------------------------------------------------------------
    
    This procedure will now attempt to DEREGISTER and
    then REGISTER an MCC global entity with the name it
    has generated.  If this is the first installation of
    DECmcc with this generated name, the DEREGISTER will
    fail with the error message:
    
        No such entity: MCC <generated name>
                Unknown Entity = MCC <generated name>
    
    This error message may be ignored.
    
    -------------------------------------------------------------------------
     and then the error that is actually displayed (and has been on each of
     the last several kits) is;
    -------------------------------------------------------------------------
    
    The requested operation cannot be completed
                          MCC Routine Error =
    %MCC-E-INV_HANDLE, software error:
    
    invalid handle parameter
    
    -------------------------------------------------------------------------
     This certainly seems to indicate that the install has failed since it
     is not the one we are allowed to ignore. However,
     the install completes and displays;
    -------------------------------------------------------------------------
       DECmcc BMS V1.0 Installation Successful
    
    
    
       Completing DECmcc BMS Installation Verification Procedure ..
    
            Installation of MCCBMS V1.0 completed at 16:25
    
     ----------------------------------------------------------------------
    
    This doesn't seem right. Also, perhaps the "Completeing ...."
    message could be removed as it seems redundant after the 
    "Installation Successful" message.
    
    s/rob
     

Like in the previous kit, the debugger keypad is not set when I break into
my Access Module after a  MANAGE/ENT/DEBUG.

It was OK in the first field test kit. Why has this changed ?

			-- Paul

Due to an error in my AM, the value of the out_entity argument is an AES which
only contains a fully wildcarded global class name ( i.e. "*").
After I return from the MCC_CALL with such a value, MCC displays a error message
and keep on running until my pagefile is FULL (!), which, in most cases,
blocks VMS.

Could someone QAR this problem.

Thanks,
			-- Paul

    
    
    RE: .12
    
    Since the FCL now owns the screen for support of the forms mode,
    the debugger and the FCL are in competition -- and FCL wins (they
    are both based on SMG). To return keypad control to the debugger
    simply enter the command "SET MODE KEYPAD".
    
    RE: .13
    
    Could you clarify the item a bit more, so that I can QAR it correctly.
    When you said it kept running until you pagefile was full, do you
    mean that you kept entering more commands, or it got into what looked
    like an endless loop?
    
    

    MCC *requires* a minimum pagefile size of 24000 blocks.  Anything less
    could be disasterous (system hangs).  This is because the process
    pagefile quota needs to be 24000 (this is documented), and having a
    pagefile size less than the pagefilequota could cause VMS to hang in a
    resource wait (trying to update modified pages to a page file that has
    no more room).
    
    Ideally, I recommend 40000 blocks for a pagefile size.  But no matter
    what size it is (as long as it's at least 24000), it should be the same
    or more than the process pagefilequota.
    
    The Alarms team just had a problem similar where the system hung when
    they tried to run many rules with too small a pagefile (20000 blocks)
    
    -Matt.

RE .14 & .15

MCC looked like going into a loop that ends when my pagefile (50000 blocks)
was full, which caused VMS to hang. My pagefile quota is 100000 blocks.

		-- Paul

    RE: .-1

    Sorry, I guess I misunderstood the problem.

    Okay.  So let me see if I understand this.  If out-entity contains a
    wildcard, MCC gets caught in an endless loop which (apparently)
    includes some memory allocation, ultimately resulting in your process
    running out of virtual memory.  Yes, I would definitely consider that a
    serious bug.

    When you say that it blocks VMS, I thought you meant that it hangs the
    VMS operating system.  If this is what you meant, then it's probably
    because your pagefilequota (100000) is greater than your page file size
    (50000).  I consider *that* behavior (VMS hangs when pagefilequota is
    greater than page file size AND the pagefilequota get used up) a VMS
    restriction.   You're welcome to disargee.

    In any event, I agree MCC has a bug.  Whether MCC *causes* your system
    to hang or not is probably more a religious issue (and is probably
    splitting hairs, anyway, i.e., let's just fix it).

    -Matt.

RE -1:

Yes, Matt, your understanding is correct. Thank you for your clear description
of the two problems.

Let me know if you can't reproduce the problem; I'll try on my side.


		-- Paul

    
    RE .13
    
    We have passed wildcards back before without incident, so I am
    wondering if it is potentionally linked to the entity. If you could
    supply the following it would be greatly appreciated:
    
    What entity class were you returning?
    Did you set the id and/or dt fields in the entity instance?
    What type of command (examine/modify...) were you exectuing?
    Was any wildcarding involved?
    If an examine directive, were multiple partitions envolved?
    Did you have a WITH clause?
    Did you have an AT clause?
    
    A print of you dispatch entry, the command executed, the output
    from the command, and the applicable MSL segment, would all help
    in debugging this (QAR #1225 in MCC_DEV).
    
    thanks
    jill
    

    ref .6, .8

    I searched the  namespace that dave has been using. For each and every  
    registration that has failed with this "duplicate identifier" error, I 
    found a corresponding back translation link pointing to a different 
    object.  

    Note that some of these problems are related to registering the cluster
    aliases, as some of the  entities involved are a cluster aliases.
    
   Again, the error message "dupilcate identifier" does not pinpoint the
   problem, but it serves the purpose. Hope to improve the messages in later
   versions of MCC.


/ Jesuraj

   

    
    RE .13 ....
    
    Well since we didn't get more details in regards to this problem
    (see .19 for reqeust). I have done the best I can to make sure the
    problem no longer  exists (MCC_DEV qar #1225). The internal process
    logic for handling call parameters has been reworked significantly
    in the V1.1 EFT kit. If any one experiences problems like the one
    mentioned in .13 please respond; otherwise the qar will be considered
    closed.
    
    Example of wildcard return in out_e:
    
    MCC> directory node4 *, in domain foo
    
    Node4
    AT 29-NOV-1990 09:41:53
    
    The requested operation cannot be completed
                MCC Unhandled Service Reply = The requested operation
    cannot be
                                              completed
                          MCC Routine Error = %MCC-E-NOPARENT,  parent
    entity does
                                              not exist
    MCC>

    I've been trying to install DECmcc-EMS v2.0, which uses BMS v1.0 for
    several days now.  I continue to get the error mentioned in .1, plus,
    once I exit MCC I can't even get DNS$CONTROL to talk to the namespace,
    as it give the same error (sometimes it even crashes the system).
    
    Do I install X1.1 of BMS (as .8 aludes to it being fixed there) or is
    there something else I should be looking for!
    
    -doug_who_is_pulling_out_what_little_hair_is_left
    
    
                                                     

                    <<< TOOK::WORK$214:[NOTES$LIBRARY]MCC.NOTE;2 >>>
                -< DECmcc Product Family; Introductions Note 6 >-
================================================================================
Note 325.8                      12-SEP-1990 Bugs                         8 of 21
TOOK::JESURAJ                                        91 lines  14-SEP-1990 11:11
                      -< Answers and things to look for >-
--------------------------------------------------------------------------------
    Dave,
    
    
    ref .1:
    
       The error message "Unable top communicate with DNS server" occurs
    when MCC is trying to read or write onto the DNS data base.
    
       The node4 registration works as follows:
            - It creates the global entity in DNS data base
    	    - It writes all other MCC realted attributes
            - It creates Synonym
    	    - It adds the Back translation
            - It adds MCC_UID link
            - Then adds  the relevant SUBENTITIES 
    
      To do each of these, MCC accesses the name server. It is possible
    that the name server is busy and the client may time out in doing any
    of the above. That is the error message  you are seeing.
    
      A solution to this problem is to place a wait loop (say 1 sec at a time,
    for maximum of 5 sec) whenever this error occured.  We have discussed
    this solution in our group, and we are planning  to include it in V1.1.
    	
    
    
    
                <<< TOOK::WORK$214:[NOTES$LIBRARY]MCC.NOTE;2 >>>
                -< DECmcc Product Family; Introductions Note 6 >-
================================================================================
Note 325.1                      12-SEP-1990 Bugs                         1 of 21
NSSG::DAVE "Dave Lyons - Networks DCC - 226-5934 - " 15 lines  13-SEP-1990 16:58
                -< DNS-E-NOCOMM, but then it deletes just fine >-
--------------------------------------------------------------------------------
I got the following error (and have been getting this error for a while) while
    trying to register a node.
    
    Of course, MCC communicates with DNS just fine to delete the parts of
    the registeration that already were created.
    
    
register node4 .DNA_Node.BBZK99 syn BBZK99
Node4 2.3 Circuit SYN-1
AT 13-SEP-1990 16:48:20


The requested operation cannot be completed
                      MCC Routine Error = %DNS-E-NOCOMMUNICATION, Unable to
                                          communicate with DNS server

    Is the problem you are running into a problem installing the other
    products of DECmcc EMS (e.g. DECnet Monitor, LTM, ETHERnim, DECelms,
    TSM) or is it in installing the DECmcc BMS piece of BMS?
    
    -Will-

    It's after the installation of BMS, when I try to REGISTER NODE4's that
    I get the DNS-NOCOMM messages.  I have a feeling that something is
    wrong with the DNS installation and startup.  If I find the problem I
    will reply here.  If anyone else can point out something else to try,
    please do so!!
    
    Thanks
    
    -doug

    Hooray!  The problem was resolved!  It was due to problems with the DNS
    install and startup.  See reference in the DNS 197.9!
    
    -doug