Conference azur::mcc

    I have Multinet 3.2 installed on my workstaion in ZKO. Although I haven't 
    tried using the DECmcc auto-configuration utility with Multinet, I have
    done extensive testing of the SNMP AM with Multinet and have worked 
    with Bruce Miller from TGV to get all known problem resolved. 
    
    I'll try using the DECmcc auto-configuration utility and post my
    finding here.     
    
    Jim
    

    re:.1
    
    Hi Jim,
    
    I work in the CSC/CS network support group.  I just finished talking to
    a customer who has TGV V3.2b installed and is experiencing a problem
    that has previously been CLD'd.  He is polling a Cisco router
    (registered as an SNMP entity) once an hour for exporting.  After his
    second successful poll, the export job seems to hang.  He doesn't get
    anymore successful polls but he is not getting any unsuccessful polls
    either.  The time of last successful poll is accurate.  This was
    reported before with exporting as well as alarms.  I have instructed
    the customer to contact TGV for a possible resolution.  Is there
    anything we can add from our end?
    
    Walt

Has he set the TCPIP AM stack size to 200?

TGV TCPIP runs a lot of code in user space (or so I am told), and requires
a lot of stack.

    Walt,
    
    Can you have the customer write some alarm rules that get the same data
    at the same rate and have them monitor the status of these alarm rules?
    It's hard to figure out what is going wrong without know the status 
    being returned by the SNMP AM. Also, does this problem occur while doing
    normal SNMP shows/sets or just when using Export, Alarms, PA, ect.?
    
    
    jim
                                                              

Hi,

The TCPIP stack size was set to 200 as recommended in the release notes.

I will ask the customer to write an alarm rule against the entity to
see what happens.  I don't believe the problem is ever observed when
issuing individual set / show commands.  It only seems to occur when
the process is trying to access the node at regular intervals.  When
I have results from the customer, I will post them.

Walt

    Hi,
    
    Update to .5:
    
    The customer setup an SNMP alarm rule that would always evaluate false. 
    The rule continued to work without hanging like the export did.  Then
    he started up the export again and after two successful polls, it hung
    again.  The export shows active but the last successful poll never
    updates again.  There are no unsuccessful polls.  The customer also
    observed that one of the two successful polls (he's not sure which one)
    had all 0's instead of good data like the other poll.  He also observed
    that while the export appeared to be hung, he could issue set and show
    commands to the same SNMP entity the export was against.
    
    Anything else you would like him to try?
    
    Walt

    Hi,
    
    The customer received a neat monitoring tool from TGV that "looked" at
    the system while the export was running.  What it found was that the
    first poll that occurred after the export had no problems.  The second
    and any additional polls were receiving something about a TYO privilege
    error.
    
    Apparently, the first export occurrs under the process that is entering
    the export directives.  After that, the exports are done by the
    background process in the queue.  The background process was running
    with TMPMBX, NETMBX and READALL privs.  The customer added a line to
    his login.com that turned on all privs for batch execution and now it's
    working fine.  He has been polling every 10 minutes for the entire
    weekend and everything has worked fine.  
    
    This sounds like overkill... Does anyone have an idea what the specific
    privs are that are needed?  I found LOGIO ahd PHYSIO but those are only
    suppose to be for our bridge statistic calculations.  I couldn't find
    any other privilege requirements mentioned.
    
    Walt

    Hi,
    
    Could someone please read .7 and give me a clue as to the process privs
    needed?  The paragraph in question is the last one in the note.
    
    Thanks,
    Walt

LOG_IO and PHY_IO are required for most AMs that do datalink ethernet access
(e.g. Bridge AM, Ethernet AM, Conc AM, FDDI AM, Vitalink AM).

I believe SYSPRV is required for SNMP AM when using UCX for at least some of
its functionality (e.g. TEST SNMP (aka "ping")). 

Maybe TGV Multinet requires it as well?

						Chris

    Hi,
    
    Thanks for the reply... I apologize for being a bit bull headed, I
    never thought to tell the customer to ask TGV what they require since
    it is their transport he is running and that's what was failing!
    
    Thanks again,
    
    Walt

    I realize this is an old note but the topic was SOOO right on I
    just had to use it...
    
    Customer Config
    ---------------
    VMS V6.1
    TGV Multinet V3.5A-X
    HUBwatch V3.1
    DECmcc V1.3
    
    After my customer upgraded the node running DECmcc to Multinet
    V3.5 A-X they couldn't start HUBwatch from the pulldown
    Application menu.  With a li'l investigation, I determined that
    the arguement */COMMUNITY= " <SNMPwrCommunity> " * in the 
    SYS$COMMON:[MCC]MCC_APPL_HUBWATCH.DEF file was the culprit.
    Donno why the "SNMP write community" variable would cause the
    DECmcc application to ACCVIO, but it did.  By commenting out
    that line in the .def file HUBwatch can now be started from
    DECmcc.
    
    Just thought you would like to know, (Enquiring minds...and all that)
    Ed Gallagher