Conference azur::mcc

    Usually when you get that error message, there are two possibilities:
    
    A) Someone aborted an MCC installation in the middle of initializing
       the MIR directory file (MCC_MIR_DIRECTORY.DAT), OR
    
    B) You are in a cluster environment and two or more members of the
       cluster have different MCC_TDF values.
    
    The first one is actually quite rare, in fact, it should be once in
    a blue moon with the X1.1 kit, since I now disable control-Y when I
    update the MCC_MIR_DIRECTORY.DAT file.
    
    The second one SHOULD be equally as rare.  Unfortunately, many users
    do not take the MCC_TDF logical very seriously.  THEY SHOULD!!!
    
    Troubleshooting:
    
    1) Check if all the cluster members have set their TDFs to the same
       value.  It is MANDATORY that all cluster members have the same
       MCC_TDF logical name value.  I will state that in the release notes
       for the next release (DTSS will solve this problem in the "near"
       future).  I am reasonably certain that your problems have to do
       with a screwed up MCC_TDF logical someplace.  You should do a
       SHOW LOG MCC_TDF for each cluster member.  If you are not doing
       a cluster install, then do the show logical anyway.  Note
       that same problems will arise if you set the logical back an
       hour AFTER the installation has completed, or if you change
       the system wide logical from other privileged process DURING
       the install.
    
    2) If the TDFs were different, then setting them to the same value
       should solve the problems. If they were already the same value,
       then do a directory of the MCC_SPECIFIC: area.  You should only
       see one file, the MCC_EVENT_POOL.DAT, if there are MIR files, then
       someone (not us) is playing around.
    
    3) The repositories are logical files.  The may map to multiple
       files, or multiple repositories may map to the same file. The
       MCC dictionary files (on VMS) are managed/manipulated as a set
       of repositories in the MIR.  The MIR routines timestamp the
       repository entries in a file called MCC_MIR_DIRECTORY.DAT.
       Someone may have set back the system time, causing the MIR
       not to be able to find the files (timestamp would then be for a future
       time).  Wait at least an hour and try again.  If it suddenly starts
       working, then someone has either been setting the system time behind
       your back (maybe another piece of software?), or the MCC_TDF logical
       was set incorrectly.
    
    4) If all else fails, you can run SYS$SYSTEM:MCC_DAP_MAIN.EXE
       ($ MANAGE/TOOL/DICTIONARY) the DAP program performs cleanup
       on the MIR files.  However, I'm not sure how much good this
       will do you, since repositories 4-7 *are* dictionary files.
    
    Hope this helps.
    -Matt.

    My mistake.
    
    The X1.0.1 kit did NOT include the toolkit components needed to
    complete the installation. You do have to put the 1.0 kit on first.
    
    I corrected this mistake in one note, but I must have missed the
    other. Sorry.

  Right, the V1.0 Toolkit should be installed first, followed by the V1.1 IFT
  BMS kit. There is no need to install the V1.0 BMS kit in order to then install the V1.1
  IFT kit.
								- Dave

    Thanks for the help.
    
    .1 got part of the problem - I had specified the TDF as "+00:00". for
    some reason the installation didn't like this ... (after I installed
    v1.0) I tried again using a TDF of "+01:00" and the installation went ok.
    
    As everybody knows, its impossible to write "idiot-proof" code -
    somebody will always find a better idiot ;-)
    
    Maybe the KITINSTAL.COM needs modifying to strip the "+" for a zero
    TDF ??? Should I report this "officially" or will the responsible
    person(s??) pick up on this from the notes file ??
    
    Richard.
    
                        

    +00:00 for TDF should work.  Sounds like a bug (my bug).  There was a
    bug in earlier kits where positive values were not working (I think it was
    just for the UT1.0.1 kit), this was fixed.  There was another bug where
    all zeroes in a delta time was interpreted by VMS as an absolute time,
    because the sign bit got cleared (no such thing as negative 0).  It may
    be that the plus value got fixed but the positive delta time bug did
    not, and that is what is causing this problem.  
    
    Maybe I should just test every possible TDF value, after all, there are
    only 48 of them :-)
    
    What version of MCC were your running? V1.0?  Is that the SSB kit?
    
    -Matt.

    Well, I just tried it.  There does indeed appear to be a bug with
    exactly all zeros for the MCC_TDF logical.  For the SSB kit, please
    do not set the MCC_TDF logical to "+00:00" (or "-00:00", or "00:00"...)
    note that "+00:01" is a workaround (yuck) until I fix this.  Other
    values seem to be okay.  Sorry, England, I did not mean to pick on you.
    
    -Matt.

    re: .5 I wasn't actually running DECmcc, but I had pre-installed V1.0
    as per .2 & .3 ... I seem to remember "+00:00" worked ok that time.
    
    (Actually it's Scotland ;-)
    
    Richard.