Conference azur::mcc

| any hints what is wrong?

    Do you have any process MCC logicals defined?

    $ SHOW LOGICAL MCC* /PROCESS

$ SHOW LOGICAL MCC* /PROCESS

(LNM$PROCESS_TABLE)

  "MCC_DICT_FILE" = "SYS$COMMON:[MCC]MCC_FDICTIONARY.DAT;"
  "MCC_DICT_LOG" = "SYS$SPECIFIC:[MCC]MCC_FDICTIONARY.LOG;"
  "MCC_MAIN_EXE" = "VMI$ROOT:[SYSEXE]MCC_MAIN.EXE;"
  "MCC_PARSE_TABLE" = "SYS$SPECIFIC:[MCC]MCC_FDICTIONARY.BPT;"
$


And as for the other system:

$      DIR/DATE MCC_SYSTEM:MCC_FDICTIONARY

Directory SYS$SPECIFIC:[MCC]

MCC_FDICTIONARY.BPT;5
                     25-FEB-1992 19:39:12.36
MCC_FDICTIONARY.LOG;1
                      5-MAR-1992 12:57:31.27

Total of 2 files.

Directory SYS$COMMON:[MCC]

MCC_FDICTIONARY.BPT;3
                     16-JAN-1992 14:18:59.71
MCC_FDICTIONARY.DAT;2
                      8-DEC-1991 02:11:19.86
 

And???

Timo

Hi,

I had the same problems with an other AM.

What I did was move SYS$SPECIFIC:[MCC]MCC_FDICTIONARY.BPT;5 to SYS$COMMON:[MCC]
and this helped.


Regards	Henk.

Allowing the .bpt file (parse tables) to get out of synch with
the dictionary (.dat file) can cause all sorts of trouble.
After copying the .bpt file, you may want to use the
DAP command "rebuilt" to force the parse table back into synch.

The next question is how the parse table arrived in sys$specific
to begin with, since the dictionary related files belong in sys$common.
Do you have any ideas?  Do we need to fix an install procedure?

-- Erik

    Well, I fought this one along time ago.  It is in this conference
    somewhere.  In my case the culprit was the TCPIP AM after using the MIB
    compiler.  It seems that when using MCC_TCPIP_MTU at some point the
    .bpt file winds up in mcc_specific.  This causes all sorts of problems
    when installing async modules after compiling a new MIB.
    
    As an aside, it also happens in T1.2.4.
    
    Steve Woestemeyer
    

It turned out that there was indeed a problem with the parsetables. Notice
that this note and note 2493 were similar problems but on DIFFERENT systems.
On one I had a problem with the ELM AM and on the other with the TSAM.
Both systems had indeed BPT files in MCC_SPECIFIC and in MCC_COMMON. 
I've rebuild the BPT files (that ended up in MCC_SPECIFIC) , than moved them
from MCC_SPECIFIC to MCC_COMMON and deleted the old ones.
Now everything seems to work. 
I cannot remember exactly what I did since I installed both modules on two
systems. But definitely one of them is placing it's BPT files in the 
wrong directory.

Thanks 

Timo

    The MCC_COMMON/MCC_SPECIFIC problems caused us no end of grief in
    developing the ELM software and in writing the installation procedure.

    Why do we need two MCC_SYSTEM locations anyway?  Erik, Jill, Jim?

Steve,

        RE: .5

	Are you saying that the .bpt file is ending up in mcc_specific:
when adding mibs on T1.2.4? 

Dan


>     This causes all sorts of problems
>    when installing async modules after compiling a new MIB.
>    
>    As an aside, it also happens in T1.2.4.
>    
>    Steve Woestemeyer

    It's mainly for cluster support.  New files are supposed to only be
    created in MCC_COMMON.  Files are read from / written to through
    MCC_SYSTEM.  The customer can set up an environment such that a
    particular cluster member uses a certain set of files local to that
    node.  The real questions should be: 1) are people using the logical
    correctly ? (probably not), and 2) are customers (as in system
    managers) taking advantage of this "feature"?
    
    For example, the MCC Dispatch tables use this algorithm and we have
    had little or no complaints to date.
        
    -Matt.
    

    I think the real problem/question here is "why does the TCPIP MIB
    compiler write parse tables to MCC_SPECIFIC".  I have been watching for
    an answer to this question since I first raised it.
    
    Steve

    Dan,
    
    re .8:
    
    Yes, in T1.2.4, after compiling mibs , MCC_FDICTIONARY.BPT shows up in
    MCC_SPECIFIC.
    
    Steve

    I seem to recall seeing a QAR against the parse table builder on this. 
    It was probably deferred because it was a low priority.  We should
    investigate bumping up the priority, especially since it is probably a
    two minute fix.  And, oh, by the way, this problem has bitten mcc
    development a few times as well (but after getting bitten enough times,
    you learn to avoid it).
    
    -Matt.

RE: DAP writing parse tables to MCC$SPECIFIC

  Starting with baselevel x1.2.14 the DAP utility changed its algorithm 
  for where it wrote the parse tables.

  The parse tables are always read/written from/to the same directory that 
  contains the main dictionary file (default name: mcc_fdictionary.dat).  The
  main dictionary file can be found in either MCC_SPECIFIC or MCC_COMMON.  This
  was done so that the files comprising the dictionary would be manipulated as
  a set.

  Please read note 2006.* for more details if you need them.

  Now, I believe (someone please correct me if I'm wrong) that baselevel 
  x1.2.14 was the first baselevel after T1.2.4 -- the v1.2 EFT kit, so you may
  not yet have these changes.

  As Matt said, the priority of this problem was indeed bumped up because it
  had become so annoying to our users.  

  Hope this answers your questions...

                                                                   - Jerry