Conference azur::mcc

    I have just encountered the same ACCVIO using a Xyplex MIB.  This
    happened right in the middle of customer training.  Needless to say, I
    need some help on this one A.S.A.P.
    
    (It actually looks like a "cascade" of multiple problems since I get
    additional X-display errors sometimes; however, the basic problem of
    the first ACCVIO mentioned below is consistent and can be reproduced at
    will.)
    
    %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
    address=0019C768, PC=000CF8EE, PSL=03c00000
    
       Improperly handled condition, image exit forced.
    
             Signal arguments              Stack contents
    
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=7FE92C00, PC=8018FB89, PSL=03C00004
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=00000000, PC=00000000, PSL=03C00000
    
       Improperly handled condition, image exit forced.
    
             Signal arguments              Stack contents
     
             Number = 00000005		     000A7C58
             Name   = 0000000C               00000000
                      00000000               00000067
                      00000000               00000003
                      00000000               7FF92264
                      03C00000               7FF94110
                                             7FF93008
                                             7FFDFE48
                                             00000001
                                             00010005
    
       Register dump
    
       R0 = 00000001  R1 = 8067B740  R2 = 00000000  R3 = 2FFC0000
       R4 = 7FE920C8  R5 = 7FE920A4  R6 = 0033A8DC  R7 = 004320F0
       R8 = 009EA6FC  R9 = 00000000  R10= 00000000  R11= 00716298
       AP = 7FE92118  FP = 7FE920D8  SP = 7FE92154  PC = 00000000
       PSL= 03C00000
    
    --------------------------------------------------------------
    ADDITIONAL INFO:
    
    I have been serving a window to another workstation.  I get the same
    ACCVIO at the same point, but I get a MAP Window Message: System error:
    An internal error has occurred in the Iconic Map PM.
    
    The DECmcc process is a memory pig.  My system was re-tuned to give it
    plenty of resources.  At the time the process dies, Working set = 10663
    and Virtual Page Count = 28026.  The IMPM requires 5MB of physical
    memory and still ACCVIOs ???  This seems a bit much.
    
    Here is the exact PATH to ACCVIO:
      1. Double-click on SNMP icon (.xyplex_ts) to see its child entities
      2. Double-click on private MIB (xyplex) to see its child entities
      3. Double-click on (character) entity to see its child entities
      4. Double-click on (charPhysTable ...) to see children.
      5. ACCVIO results, DECmcc terminates with all windows disappearing.
         On one occassion, the process completely terminated and the 
         process window disappeared.
    
    -Dan
      

    .0,.1  Do you have any rules enabled at before the lookinto operation
           occurs?   
    
    	   Is the accvio reproducable, always occuring after a specific
     	   set of user interaactions?  Or does it happen at different
    	   times but always when you are looking into something?
    
    	   Could one of the mib extentions be corrupting memory?  Try
    	   defining MCC_LOG to be 4020 and re-running.  Do you get
    	   any FAKE_VM messages displayed?  (note: you will probably
    	   need to ^Y out of the iconic map when exiting.  Defining
    	   this generates lots of infomation displayed to the screen
    	   upon exiting.)
    
    	   Also try doing the FCL equivilents.  The open domain 
    	   issues a 
    		SHOW DOMAIN <dom> MEMBER * ALL CHAR
    		
    	   The lookinto issues for each child with dynamic=false
    
    		SHOW <entity> <instance> <child> * all ident
    
    	   Also do the above with MCC_LOG = 12.    
    
    /Jim
    
    	p.s. I am assuming that the v1.1 BMS kit is installed.

    Jim,
    
    	The problem can easily be reproduced.  Look at the last part of .1
    to see additional info (after the register dump).  I've detailed all of
    the steps.
    
    	There are NO rules enabled.  Also, as mentioned in note 1715,
    MCC_IM_LOG did not like me much the way I had it set.  I'll define
    MCC_LOG to 4020 and try again.
    
    -Dan

Same problem happening this side using the Wellfleet MIB extensions. This used
to work 'somehow' with the 1-oct-1991 kit. It does not with the latest one.
Clicking on the Wellfleet router icon and selecting the Decnet routing table to 
displayed ACCVIOs DECmcc. Looking into standard MIB stuff (interface i.e.) works
OK.

Setting MCC_LOG to 12 gives the following

IM__CALL_SCHEDULE - Current time:  6-NOV-1991 14:58:13.91
mcc_call_access - Time of request ->  6-NOV-1991 14:58:13.92
MCC_CALL_FUNCTION - Dispatching to procedure MCC_DOMAIN_SHOW
mcc_call_function - Time of request ->  6-NOV-1991 14:58:19.09, 27 call(s)
IM__CALL_SCHEDULE - Current time:  6-NOV-1991 14:58:19.11
mcc_call_access - Time of request ->  6-NOV-1991 14:58:19.12
MCC_CALL_FUNCTION - Dispatching to procedure MCC_DOMAIN_SHOW
mcc_call_function - Time of request ->  6-NOV-1991 14:58:47.52, 28 call(s)
IM__CALL_SCHEDULE - Current time:  6-NOV-1991 14:58:47.54
mcc_call_access - Time of request ->  6-NOV-1991 14:58:47.55
MCC_CALL_FUNCTION - Dispatching to procedure mcc_control_emm_passthru
mcc_call_access - Time of request ->  6-NOV-1991 14:58:47.73, 1 call(s)
IM__CALL_SCHEDULE - Current time:  6-NOV-1991 14:58:47.74
mcc_call_access - Time of request ->  6-NOV-1991 14:58:47.75
MCC_CALL_ACCESS - Dispatching to procedure mcc_tcpip_am__show
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=
0019CDD4, PC
=000CFCEE, PSL=03C00000

  Improperly handled condition, image exit forced.

        Signal arguments              Stack contents

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=
7FF25800, PC
=8089B589, PSL=03C00004


setting MCC_LOG to 4020 gives

Memory:    Size: 00001000    Addr: 00171DB8     No errors     From PC: 001165FB
        From PC: 00115C27 From PC: 00115CF9 From PC: 00116175 From PC: 00115942
        From PC: 00005867 From PC: 0000580E From PC: 000057C6 From PC: 808CAD89
 001823E0 FFFF0001 001824C0 FFFF0001 ....�$......�#.. 000000
Memory:    Size: 00000090    Addr: 00171C40     No errors     From PC: 7FF7F61D
        From PC: 7FF7F75D From PC: 0000200E From PC: 00001C2B From PC: 000057C6
        From PC: 808CAD89 From PC: 7FF7B738 From PC: 7FF7B69A From PC: 00000000
 00000000 00000000 00000000 00000000 ................ 000000
FAKE_VM string processing has been *disabled*
FAKE_VM has announced 0 errors
No erring packets found
FAKE_VM string processing has been *disabled*
FAKE_VM has announced 0 errors
%MCC-E-ABORTCTRLY, image aborted by Ctrl\Y
003_$ 

Ernesto,

	It would be real helpful if you'd issue the following command from
fcl,

MCC> sho snmp xyz wellfleet wfdrs wfdrsnoderoutingtable * all ident

and either mail me a log or post the results here.

Thanks,

	Dan

    I got EXACTLY the same results as in 1687.4 when using the Xyplex private
    MIB via IMPM with MCC_LOG defined to be 4020 (no errors reported).
    
    The FCL interface works just fine.  Also, the 01-OCT-1991 kit worked
    fine for me, too.
    
    FYI:
    The command
         MCC> show snmp xypts1 xyplex character charphystable * all char
    produces a fine listing of all port characteristics.
    
    Still need to try same commands with MCC_LOG defined to be 12.
    
    I die at exactly the same level in the MIB tree every time with the
    same errors.   Looks like 1687.4 is dying there, too, but using a
    different vendor MIB.
    
    I can't send a log, but would be happy to work with someone over the
    phone.
    
    -Dan (303)-649-3240 

Re .5

Dan,

I mailed you a session log showing the results of the command you asked
me to perform on the router box. It works. 
Regards
Ernesto

    Here is some more info with MCC_LOG defined to be 12.
    It seems that the problem is in the   mcc_tcpip_am__show  procedure.
    
    Also, here is the Private MIB structure for XYPLEX:
    
    xyplex
       xsystem  (no children)
       character
           charPhysTable...
           charPhysInSignalTable...
           charPhysOutSignalTable...
       xInternet  (no children)
    
    If I select "xInternet" or "xsystem" and perform SHOW operations on
    these entities, I can cause a ACCVIOs and MCC IMPM shoots up an
    "Internal Software Error" message.
    
    If I look into any of the child entities of "character", the IMPM
    ACCVIOs as indicated in the log below:
            (Note: My comments to the log are made in <<  >>)
    --------------------------------------------------------------------
    << several calls are made initially to MCC_AMARMS_GET_EVENT,      >>
    << MCC_DOMAIN_SHOW, and mcc_notif_notify during MCC IMPM startup. >>
    << From "176 call(s)" on down is log info resulting from looking  >>
    << into "xyplex".  ACCVIO results when looking into               >>
    << "charPhysTable..."                                             >>
    
                             .
                             .
                             
    mcc_call_function - Time of request ->  7-NOV-1991 08:41:32.68, 175 call(s)
    IM__CALL_SCHEDULE - Current time:  7-NOV-1991 08:41:32.70
    mcc_call_access - Time of request ->  7-NOV-1991 08:41:32.71
    MCC_CALL_FUNCTION - Dispatching to procedure MCC_DOMAIN_SHOW
    mcc_call_function - Time of request ->  7-NOV-1991 08:56:34.44, 176 call(s)
    IM__CALL_SCHEDULE - Current time:  7-NOV-1991 08:56:34.47
    mcc_call_access - Time of request ->  7-NOV-1991 08:56:34.49
    MCC_CALL_FUNCTION - Dispatching to procedure mcc_control_emm_passthru
    mcc_call_access - Time of request ->  7-NOV-1991 08:56:34.88, 1 call(s)
    IM__CALL_SCHEDULE - Current time:  7-NOV-1991 08:56:34.89
    mcc_call_access - Time of request ->  7-NOV-1991 08:56:34.91
    MCC_CALL_ACCESS - Dispatching to procedure mcc_tcpip_am__show
    %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
    address=0019C968, PC=000CF8EE, PSL=03C00000
                       .
                       .
                       .
    
    Please let me know if you need more.
    
    -Dan

    Here is the log resulting from defining MCC_TCPIP_AM_LOG equal to 2. 
    Again, looks like problem is in   mcc_tcpip_am__show.
    
    $ ICONIC_MAP_PM
    
          << Entering mcc_tcpip_am__show >>
    %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
    address=0019C968, PC=000CF8EE, PSL=03C00000
    
      Improperly handled condition, image exit forced.
                   .
                   .
                   .
    

    This looks just like a condition I am seeing at a customer site.
    
    In our case we are using the Synoptics MIB.
    
    We found that double clicking on the icon followed by double clicking
    on the SYNOPTICS child followed by double clicking on one of the
    tables got us the ACCVIO BUT if at each stage we did an operation
    before going to the next level, it worked. Oh, and yes, the FCL
    worked for us too.
    
    s/rob

	We're looking into this problem. They'll be more info here as it becomes
available.

Dan

Re. .10

What version of the product is being used? Is it the Oct 1st Kit? This is the
same behaviour I had remarked using that release, this why a couple of replies
earlier I mentioned that accessing the extensions did work somehow. 
After installing the Oct. 23rd kit however, this trick did not work any longer.

Ernesto

	The ACCVIO is occuring because we're running out of stack space in the
thread created by the MAP.  The routine that reads in vendor private extensions
from the dictionary has some stack allocated buffers that were increased late
in the game to solve a problem reading in the Banyan MIB.  Unfortunately
in our haste to solve the Banyan problem we didn't do the requisite testing
with the MAP to make sure we didn't break anything. 

	In any event, there's a new mcc_tcpip_am.exe that should fix the problem
on MOLAR:: in 

Directory DANZO_USER:[CARR.PUBLIC]

MCC_TCPIP_AM.EXE;4      174  12-NOV-1991 14:05:50.25  (RWED,RWED,RWED,R)

Total of 1 file, 174 blocks.

   It will help us if you all would install this image on your (or your 
customer's) systems and help us verify that the problem has been solved.  The 
new image should be copied to sys$common:[syslib], then run 
sys$startup:mcc_tcpip_startup.com to install the image and enroll it.

Thanks,

	Dan

	I've updated the image yet again, this time to change the version
number returned from a show mcc 0 tcpip_am all char,

DECmcc (V1.1.0)

MCC> sho mcc 0 tcpip_am all char

MCC 0 TCPIP_AM
AT 12-NOV-1991 15:45:10 Characteristics

Examination of attributes shows:
                      Component Version = V1.1.1
               Component Identification = "DECmcc TCP/IP SNMP AM"
                            UDP Timeout = 5
                            UDP Retries = 2
  

	This'll make it a bit easier to distinguish between this AM and the
SSB version. 

	The file is in the same spot as mentioned in -.1,  MOLAR::

Directory DISK$DANZO_USER:[CARR.PUBLIC]

MCC_TCPIP_AM.EXE;5      174  12-NOV-1991 15:40:00.38  (RWED,RWED,RWED,R)

Total of 2 files, 174 blocks.

Dan,

We installed the new image this morning and we can access the Wellfleet
extensions again. Many thanks!
Regards
Ernesto

    Dan,
    
    	You guys did a fine job.  Xyplex MIB variables are accessible again.
    Your timing couldn't be better.  Customers will begin using the AM
    tomorrow.
    
    Thanks,
    -dh