Conference azur::mcc

Rob,

When you do a file-open it plants the root of a navigational tree.  The tree is
actually upside down.  Whenever you doubleclick on something the tree grows 
downward.  We look for map files only when growing the tree downward.  Look-up 
just moves the user up towards the root.  We do not look for map files when
moving up or when we are retracing a downward path.

Doing a file-open or file-new blows away any existing tree and starts a new
one

Fred

    I just rebooted my system after extending my pagefile and relocating
    all the MCC_COMMON, MCC_ICONS, and MCC_MAPS stuff to a DFS disk.
    
    I editted the MCC_LOGICAL_DIR.COM file to add the MCC_ICONS and
    MCC_MAPS logicals and to redefine where the MCC_COMMON area was.
    
    I wasn't surprised to see the logical name redefined messages when
    the MCC_STARTUP_DIR file ran but I was surprised to see them again
    when the MCC_STARTUP_BMS file ran. Shouldn't the BMS startup just
    leave them alone since the DIR startup just finished setting them up?
    
    Also, when I did the pair of startups I got this result.
    
    
    mgr> @sys$startup:mcc_startup_dir
    
    
    The MCC_STARTUP_DIR startup procedure for DECmcc X1.0.1 is now running.
    
    %DCL-SUPERSEDE, previous value of MCC_CR has been superseded
    %DCL-SUPERSEDE, previous value of MCC_COMMON has been superseded
    %DCL-SUPERSEDE, previous value of MCC_ICONS has been superseded
    %DCL-SUPERSEDE, previous value of MCC_MAPS has been superseded
    DECmcc (X1.1.0)
    
    MCC 0
    AT  3-OCT-1990 18:20:45
    
    
    Test Successful
    
    
    The MCC_STARTUP_DIR startup procedure for DECmcc X1.0.1 is now ending.
    
    mgr> @sys$startup:mcc_startup_bms
    
    
    The MCC_STARTUP_BMS startup procedure for DECmcc X1.0.1 is now running.
    
    %DCL-SUPERSEDE, previous value of MCC_UIL has been superseded
    %DCL-SUPERSEDE, previous value of MCC_ICONS has been superseded
    %DCL-SUPERSEDE, previous value of MCC_MAPS has been superseded
    DECmcc (X1.1.0)
    
    %MCC-E-FILEINUSE,  file is still in use
    %MCC-E-FILEINUSE,  file is still in use
    %MCC-E-NOTFOUND,  unsupported combination of verb, entity, partition
    %MCC-E-NOTFOUND,  unsupported combination of verb, entity, partition
    
    
    The MCC_STARTUP_BMS startup procedure for DECmcc X1.0.1 is now ending.
    
    mgr>
    
    
    Also, as another side effect, my definition of MCC_ICONS and MCC_MAPS
    was not there after even though my definition of MCC_COMMON was.
    
    ????
    
    s/rob

    RE:.2
    
    Rob,
    
       There are only two reasons that I can think of for getting the
    %MCC-E-FILEINUSE,  file is still in use
    error message.
    
    1)  Someone (or something) has a MCC file locked for exclusive access and
        does not want to let go of it.
    
    2)  You (or someone/something) else is accessing one of the MCC files
        through DFS.  
    
    The first possibility is small because only MCC should be playing with
    the files, and all files are opened with full shared access.
    
    The second possibility happens more often.  This is because DFS does
    not support SHARED WRITE access, but pretends that it does.  Most of
    the time, there is not a problem.  For example, MCC opens the
    Dictionary/Definition files as shared read-only.  So if you have DFS
    access to the Dictionary/Definition files, you are probably okay. 
    However, if you go into DAP using DFS to access the dictionary, then
    everyone else who tries to run MCC will suddenly get "File is still in
    use", because DAP opens the dictionary files as SHARED WRITE.  The same
    thing happens with the MIR Directory files.  They start out as being
    opened with shared read-only access.  Once someone tries to create a
    repository, the files get re-opened with SHARED WRITE access, so that
    the new repository information can be added (for example, when Alarms
    is enrolled, or when Historian/Export is running).  If someone uses DFS
    to access the MIR common files AND is creating repositories, then
    anyone else running MCC gets "file is still in use".  Note that there
    is no way that I know of to determine (using RMS) if the file(s) are
    being accessed through DFS.  If/when the MIR routines support "remote"
    repositories, this problem will be solved.  Please let us know if this
    is NOT a DFS/MIR interaction problem.
    
    Thanks,
    -Matt.
    

    It is certainly a DFS interaction problem. I am trying to share things
    with multiple workstations with a common MCC_COMMON:. I have no idea
    which directives are going to write to files in MCC_COMMON.
    
    However, when I got these errors I was the ONLY user of MCC and the
    files in MCC_COMMON so I don't know why I should have a problem.
    
    Whats a DAP? I don't know if I went in to it?
    What would "Create a Repository"? I don't think I asked it to do that.
    
    All of the things we were trying to do when this came up were only
    looking or displaying things.
    
    Perhaps the errors should include the file name that is a problem?
    (Actually, that should be expanded as a general thing for all errors
     that the user sees from MCC - even after almost 6 months of using
     baselevels of MCC, the error messages continue to have inadaquate
     information for support of the product)
    
    thanks
    s/rob

    RE:.4
    
    Sorry.  I think we should have two notes files.  One for end users,
    one for developers.  DAP manages the MCC dictionary, repositories
    are like logical files they are information stores.
    
    Unfortunately, it looks like MCC does not support DFS access to
    the MCC_COMMON directory.  This is more of a DFS restriction 
    than an MCC restriction.
    
    -Matt.