[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

6387.0. "REF: 6385/MCC Hanging up frequently" by USOPS::PLANG () Sun Oct 08 1995 05:39

    Ref: 6385, we have been experiencing problems with DECMCC hanging up
    at least once every two to four days since upgrading vms to 6.1 and to
    decnet/osi. This has been almost a year. Colorado has been contacted
    and can't seem to isolate the problem. We know that on one occasion
    MCC hung when a PURGE command was executed. Has anyone else experienced
    similar problem? We will be going to NetVue at some point in the future
    but would like to be able to fix the current MCC problems. Anybody
    have any troubleshooting ideas?
    
    Thanks,
    
    Pam
T.RTitleUserPersonal
Name
DateLines
6387.1dispatch tables, rebuild, Rdb maint, et alDPDMAI::GALVINThe Energizer Bunny's Trainer...Tue Oct 17 1995 18:4060
    Pam,
    
    You might want to try rebuilding the dispatch tables for MCC.  It's in
    SYS$STARTUP:MCC_STARTUP_BMS.COM; if you uncomment the P1 parameter,
    ENROLL, it will rebuild the dispatch tables.   This should be performed
    with an entire system reboot.  You should put the comment back in after
    you've rebooted, since this can be timely if you reboot frequently...
    
    Another "tip" might be to rebuild your data dictionary.  There's a note
    in one of the system admin type guides on how to do this and you have
    to have the toolkit software installed...  Do you have EMS or BMS?
    
    To activate this, you'll want to turn off all IMPM sessions, and then
    type, $MANAGE/TOOLKIT
    DAP> REBUILD
    DAP>EXIT
    
    If you have MCC turned on somewhere, the procedure will let you know up
    front, by telling you that READ ONLY is your mode... this will NOT
    enable you to rebuild.
    
    Please be sure to allocated copious amounts of free time to do the
    above.  Depending on your entities, this could take an entire
    evening...  Best to perform this after hours when no one is on your MCC
    network platform.
    
    You say that your system hung when you were doing a PURGE.  Was this
    within MCC?  Purging EXPORTER files?  Or something like that?  If it
    hung on a DCL PURGE, you might want to consider looking at your
    AUTHORIZE or SYSGEN parameters...
    
    If it's EXPORTER PURGE, you'll need to look at your Rdb database files.
    I'm not an Rdb wizard, but there's got to be some sort of Rdb
    maintenance that you can perform when they get tooooooooo BIG!  Try
    looking at Rdb HELP.  Remember, when you do any Rdb maintenance, ensure
    that the batch jobs in MCC$EXPORTER or whereever you call your batch
    jobs for your EXPORTER background processes resides, are turned OFF!
    You don't want to destroy any database files...smiles.
    
    Now, here's the last bit of *experience* you might want to draw from.
    If you are doing EXPORTing, for reporting on information, you might
    want to do a total evaluation of your PROCESS.  My experience, years
    ago, was that the EXPORTER took up lots of resources... A really nice
    developer in Littleton, MA helped me through some painful experiences
    about 3 years ago.  His names escapes me...
    
    You haven't described your h/w, so I'll assume you've got a VAX4090A?
    128mb memory?  lots of disks... 3-5 gig?  If you don't have that,
    you're in trouble...  do a, $MONITOR SYSTEM and see where your VMS is
    at when you experience hangs, etc.  
    
    If none of the above proves to be useful.... I'll tell you all about my
    experience with PolyCenter NetView, since you've stated that's where
    you're migrating to...smile.
    
    cheers & good luck,
    
    /Mic