Conference azur::mcc

>%DAP-S-USE_DICT_RDONLY, Using dictionary file: $220$dia2:[mcc_common]mcc_fdictio
>nary.dat;2, with read-only access

This most often means that someone has the dictionary open for read,
which means there is a lock held, and DAP can't write to the
dictionary.  Are you positive that all DECmcc processes
(including event sinks, export batch jobs, etc) were stopped
before you tried the ELM upgrade?

-- Erik

Since we've installed DECmcc T1.2.7 we've been seeing the same things appear in
other applications which read the MCC dictionary. Whereas I understand your need
to synchronize access to the dictionary and binary parse tables, IMHO you could
have done it without the BIG hammer.

The requirement that a system manager track down ALL  DECmcc processes (including
event sinks, export batch jobs, etc) AND ALL applications that read from the 
MCC dictionary BEFORE performing an installation is RIDICULOUS!  Why not just 
tell the system manager to boot up minimally?

-- Nestor

    Minimally, there should be an DECMCC_SHUTDOWN.COM command procedure
    which finds out any/every process running MCC/accessing the dictionary
    and stops it in an elegant fashion if possible, if not, then it should
    just kill it.  The Dictionary problem I believe is considered a bug
    that was too big to fix right, so that work-around of saying "go away
    until I have sole access" was needed in the short term.
    
    Sometimes we open peanuts with thermonuclear devices. :-)
    
    -Matt.

%DAP-S-USE_DICT_RDONLY, Using dictionary file: $220$dia2:[mcc_common]mcc_fdictio
nary.dat;2, with read-only access

    I've also gotten this error message when I forgot to turn on privs
    before doing the installation.  You might want to check that.

Hi,

I always thought that one of the benefits of DECmcc was the ability to 
install additional management modules on the fly without shutting anything 
down. It used to work in V1.1. Is this no longer ture for V1.2?

Paul.
 

Two things crept in to V1.2 that cause this to no longer work well.

1) A number of modules cache the parse tables.

2) We found that multiple users of the dictionary during a dictionary
   update can cause corruption.  This was found late in the development
   cycle, and the only solution possible in the remaining time was
   to require single user access for a dictionary update.

We are unhappy about this, but have to live with it for this version.

If you've got the disk space to burn, a work-around is to make a second
copy of the dictionary file.  Then run your installation procedure.
Just make sure that when you make the copy, there are no processes
running with the dictionary open for write.  The TSAM installation
does this for you if there is enough disk space.  After the installation is
over, purge...

I don't know if all of these other processes start up and stop, possibly
'sneaking' in and grabbing the second copy before your dictionary update
runs though... Can some one in the know confirm that?

-Dave

During normal steady state operation, DECmcc processes do not stop and
start on their own.

	I did stop all event sinks and data collectors and there were no 
exports active but I missed the MCC_TS_AM_SRV process. I'll stop it and 
try again.

	It's only a test setup but I wouldn't be very happy about having 
to take down a live MCC system just to add in another module (especially 
as it takes a significant amount of time to update parse tables etc.)

regards,
	Ian

	I missed a user process which had a MCC subprocess. Stopping this 
process allowed the installation to succeed. The only abnormal messages 
during the installation were as follows -
.
.
.
Processing file $220$DIA2:[MCC_COMMON]MCC_NOTIFICATION_FM.HELP
Processing file $220$DIA2:[MCC_COMMON]MCC_PA_BRIDGE_FM.HELP
Processing file $220$DIA2:[MCC_COMMON]MCC_PA_FM.HELP
Warning - Duplicate Key: 2PAPA
Warning - Duplicate Key: 2PAPAzCHAR
Warning - Duplicate Key: 2PAPAzCHARzCOMPONENTzIDENTIFICATION
Warning - Duplicate Key: 2PAPAzCHARzCOMPONENTzVERSION
Warning - Duplicate Key: 2PAPAzSHOW
Warning - Duplicate Key: 2PAPAzSHOWzCHAR
Warning - Duplicate Key: 2PAPAzTEST
Warning - Duplicate Key: 2PAPAzTESTzEXAMPLES
Warning - Duplicate Key: 2PAEzBRIDGEzLINEzSTATS
Processing file $220$DIA2:[MCC_COMMON]MCC_STM_FM.HELP
Processing file $220$DIA2:[MCC_COMMON]MCC_TCPIP_AM.HELP
.
.
.

regards,
	Ian

Just for future reference, the MCC_TS_AM_SRV does not access the
dictionary, so killing it to install other AMs is not required.

-Dave

    Can't Invoke DECmcc's Iconic Map after the ELM AM T1.2.7 installation, 
    with MCC BMS T1.2.7 (worked ok before the installation)

    Only error with installation was a few warnings about Duplicate keys
    with the following initial string "2PAPA*" as in re.10 

    I have since re-installed DECmcc T1.2.7, but the problem continues.
    I am for the moment unable to use the MCC Iconic Map.

    regards,	Gil

    P.S.  I have attached two process dumps, one gotten after the ELM 
    installation and the other after the DECmcc BMS T1.2.7 re-install.
    
    I did forget to save the MCC_DISPATCH_TABLE.DAT before installing
    ELM, but the Re-install should have taken care of it.
    
    Next try... delete all files in MCC_COMMON and re-install BMS ???




EDCIS_MCC$ mcc_d !invoking the Iconic Map

 No input bitmaps found for CONCENTRATOR
 No input bitmaps found for FDDI

!Outputes the two lines above, then puts up the Iconic Map Window. But before
!it finishes (just after it puts the default domain name in the window top)
!it outputs the following stack dump and the MCC process dies.

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000020, PC
=80000010, PSL=03C00004

  Improperly handled condition, image exit forced.

        Signal arguments              Stack contents

        Number = 00000005                80274640
        Name   = 0000000C                00000002
                 00000000                0016DC04
                 00000020                0016DBEC
                 80000010                00000004
                 03C00004                0016E060
                                         00000000
                                         06341C74
                                         006E284C
                                         05000001

        Register dump

        R0 = 03C00000  R1 = 00000020  R2 = 00002840  R3 = 0016DE34
        R4 = 00000000  R5 = 00000000  R6 = 03268009  R7 = 006E284C
        R8 = 006E2840  R9 = 00000001  R10= 000BDBD0  R11= 000DF140
        AP = 0016DBA0  FP = 0016DB60  SP = 0016DBDC  PC = 80000010
        PSL= 03C00004

EDCIS_MCC$


!same behavior as above, except that it doesn't output the two ELM information
!lines. 

EDCIS::SYSTEM$ mcc_d
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0016EA00, PC
=000521E0, PSL=0BC00004

  Improperly handled condition, image exit forced.

        Signal arguments              Stack contents

        Number = 00000005                00000200
        Name   = 0000000C                00E7A3B0
                 00000004                006A2418
                 0016EA00                006AD8A0
                 000521E0                0067EA38
                 0BC00004                006A2430
                                         00000001
                                         00000001
                                         00007800
                                         00000400

        Register dump

        R0 = 063497E4  R1 = 00E7A3BC  R2 = 0000A3B0  R3 = 0016DE34
        R4 = 00000000  R5 = 00000000  R6 = 03268009  R7 = 00E7A3BC
        R8 = 00E7A3B0  R9 = 00000001  R10= 000BDBD0  R11= 000DF140
        AP = 0016DBE0  FP = 0016DBA0  SP = 0016DC1C  PC = 000521E0
        PSL= 0BC00004

EDCIS::SYSTEM$

| No input bitmaps found for CONCENTRATOR
| No input bitmaps found for FDDI

    This should not happen if the ELM kit was installed successfully.  Can
    you check your MCC logical names and see if there are files in
    MCC_SPECIFIC?

| Next try... delete all files in MCC_COMMON and re-install BMS ???

    Yes, unfortunately.  Please read the release notes for ELM before
    installing that kit.  If MCC logicals are not set up correctly, or
    there are old files in MCC_SPECIFIC this can cause lots of problems. 
    The BMS kit for VMS takes about 40 minutes to install and ELM takes 30
    minutes so it shouldn't take too much time to redo it.  Please try to
    save the installation log for ELM if you can.  That may help us if this
    problem persists.

    
    I did follow the release notes, including removing all old files 
    from MCC_SPECIFIC. The only file there now, is MCC_DNS_SETUP.DEF 
    and its dated 11-May-92. 
    
    I deleted all files in mcc_common, and all mcc files in sys$help. 
    Then did a virgin installation of DECmcc T1.2.7, but it didn't
    help much. The error message changed but I still can't invoke the 
    Iconic map.
    
    I now have the exact same problem as reported in note 2795.*, 
    (as noted there I seems that VMS v5.5-1E7 and MCC T1.2.7 don't like 
    each other).
    
    Gil

PAPA messages are due to duplicate keys into the help text, you can
ignore them. They need to be fixed, both PA and ELMS are trying to
put inthe same topics.