Conference azur::mcc

From doing a SET WATCH it appears that MCC_FCL_PM>EXE is the image running
and MCC_FDICTIONARY.DAT is the file being accessed...

Lee

Mystery deepens:

I can take my saved [MCC...] directory and restore it to the original host
platform and MCC works just fine.

I copied my MCC_FDICTIONARY.DAT file from the 'working' system to the
'noworking' target system and did a DIFF/MODE=HEX and they are identical!

Can anyone hazzard a guess as to why things are crapping out on my target
platform?

Thanks-

Lee

>Can anyone hazzard a guess as to why things are crapping out on my target
>platform?

Hi, I had some problem with DECmcc V1.1 when i did some VMS system management
and by misstake set the system time back one year.

Just a thought /Stefan

    The error message sounds like something coming from DAP when the
    Dictionary is opened noshare.  But that doesn't make too much sense
    right after the BMS startup command procedure is run.
    
    You could try a show device/file on the device which has the MCC
    dictionary on it a see which process has the dictionary locked.
    But I have a feeling that won't give you much more information.
    
    Since you're on a different machine, one thing you *should* do,
    is re-enroll:
    
    	@sys$startup:mcc_startup_bms ENROLL
    
    That will give you "clean" dispatch tables.
    
    Finally:
    Since MCC seems to have started up okay, I would ask the TSAM people. 
    I assume that TSAM was running previous to the move over.  Perhaps you
    need to move some TSAM files over which are not stored under [MCC...].
    Or perhaps they store some device-specific information someplace.
    
    Re-installing TSAM would probably not be as painful as re-installing
    MCC, right?
    
    -Matt.
    

Re: .3

Time is set properly.


.4>You could try a show device/file on the device which has the MCC
.4>dictionary on it a see which process has the dictionary locked.
.4>But I have a feeling that won't give you much more information.

Nobody has any MCC files open on the device.
    
.4>Since you're on a different machine, one thing you *should* do,
.4>is re-enroll:
.4>
.4>     @sys$startup:mcc_startup_bms ENROLL
.4>
.4>That will give you "clean" dispatch tables.
    
New hardware, yes but same VMS, same DECnet name/address. I guess I'd better
read up on what ENROLL does....

.4>Finally:
.4>Since MCC seems to have started up okay, I would ask the TSAM people. 
.4>I assume that TSAM was running previous to the move over.

Yes, TSAM was running fine before the move. TSAM does not seem to be the
culprit... just doing a '$ MANAGE/ENTERPRISE' results in the error
message.

The BMS startup probably installs the MCC image(s) but does not invoke
them.  The TSAM startup is probably the first MCC 'product' that actually
tries to run MCC, thus it appears to be the naughty one- but it actually
is not.

.4>Perhaps you need to move some TSAM files over which are not stored
.4>under [MCC...].  Or perhaps they store some device-specific
.4>information someplace.

It would be rather rude of TSAM not to have files in MCC_COMMON or in
the VMS system directroy tree somewhere... in either case, I have all
[MCC...] and VMS files restored on the new system... just split onto two disks
instead of one. Everything should be there....

Lee

.4>Since you're on a different machine, one thing you *should* do,
.4>is re-enroll:
.4>
.4>     @sys$startup:mcc_startup_bms ENROLL
.4>
.4>That will give you "clean" dispatch tables.
    
Alas... tried that... same message as in .0

Can someone shed a clue as to what generates the error message in .0?

Lee

    I would guess that the dictionary is screwed up somehow.
    
    Try running DAP:
    
    $man/tool/dict show
    
    
    see if any error message(s) come out.
    
    -Matt.

Well, I knew it had to be something simple... and the answer was in .0
all along...

Current logicals:

  "MCC_COMMON" = "_DKA200::[MCC]"
                         ^^

Seems when I edited MCC_LOGICAL_DIR.COM I managed to fat-finger in two colons
instead of one... thus the above result.

Thanks for all of the above suggestions and your putting up with my imploring
for help... it was driving me crazy because it seemed sooooo basic of a
problem.

Lee Roth

Request for comment:

>        Unable to run DECmcc, installation or upgrade in progress. 
>        DECmcc dictionary currently in use, please try again later... 
>        %MCC-F-DBFATAL, fatal data base internal error
        
The message that resulted in this case (in my opinion) was misleading... I was
troubleshooting a file corruption problem when, in reality, it could not find
the database at all.

Is there any chance that things could be changed so that a more helpful
message (i.e. "MCC-F-FNF, filename.ext, file not found") could result in a
situation like this?

Thanks-

Lee

    The message originates from the FCL/IMPM PM library.  Which starts up
    and "touches" the dictionary.  If anything other than NORMAL comes
    back, it assumes (incorrectly in this case) that the dictionary cannot
    be opened because an installation/upgrade has the file locked.  More
    over, the low level dictionary routines actually will print out an
    error message much like what you describe if there are initial problems
    with the dictionary.  I think the reason that you threw the dictionary
    routines for a loop is that the logical actually expands to valid file
    spec on VMS (DKA200:: is a valid node name).  It's only further down
    in the processing that it realizes that the dictionary can't possibly
    be accessed with that file spec.
    
    I guess I could qar the Dictionary routines for letting the user
    get as far as he did without complaining.
    
    -Matt.