Conference azur::mcc

    The MIR routines were implemented on top of RMS Indexed files because
    RDB is not thread-reentrant.  In other words, RDB calls "block" the
    process.  The development required to work around this restriction was
    considered too great for the potential performance gain (for example,
    spawning a subprocess, and piping requests to it).  RMS, on the other
    hand, allows for multiple threads of execution during an RMS call, and
    the resulting code is simple.  In addition, it was (erroneously) felt
    that MCC would never run on anything but VMS at the time of the
    original development.  The next generation of RDB (whatever we call
    it), is planned to be multithreaded, and we had planned to migrate to
    it, as soon as it became available.  The Exporter does not allow
    multiple MMs to read and write to RDB simultaneously, which the MIR
    routines would have to do.
    
    -Matt.
    

    Another reply to your first question....
.0>    	1. Why MIR is implemented as ISAM file not RDB.   For consistency,
.0>           it seems logical to use all RDB or all ISAM files.
    
    I guess if we had implemented MCC using Rdb, then someone could ask the
    question
    	why did you use Rdb rather than ISAM files?
    
    So I guess the question back to you is:
    	why do you care how we implemented it?
    	what do you want to do that you can't?
    
    Matt, in .1, answered some of the technical reasons behind our
    decision. But there are other considerations too.....
    
    Colin

    I would also refer you to the discussion of SUN Net Manager and the
    reply that states that it performs rather well because it uses flat
    files rather than a relational data base. There is a performance
    advantage in using RMS rather than RDB. The simple answer of all
    RDB or all RMS sounds great but simple answers sometime create
    performance issues. We should match our implementation to the
    useage requirements. If RDB can match the performance of RMS across
    the board, then the simple answer is the right answer. If not, we
    should look for a more elegant answer.
    
    wally

    If MIR uses RDB, you save the export procedure to generate a RDB file 
    first and use it to generte historical report or graph.  If you use 
    ISAM files, with DTR you should be able to generate report or graph 
    from it without generating a RDB first.  All RDB or ISAM keep DECmcc 
    more simple.  
    

    you are assuming that the storage format is directly usable by an
    external report writer or query tool.    This is NOT the case in MCC 
    which has to deal with an unknown and potentially infinite number of
    "schemas" - data is stored in a generic format (in the current design)
    and you will always have to export it.
    
    There is also another argument for not letting your real-time database
    also be simultaneously used by browsing and reporting function due to
    the possibility of interference (performance, locking, etc) with the
    critical real-time functions.    There are many commercial applications
    where databases are exported for query/report purposes even when their
    schemas are directly usable by external programs.
    

    
    >>   3. Does DECmcc Alarm and recording support wildcard? How you
    >>           set alarm or recording for a network of more than two
    >>           hundred nodes?
    
    
    Alarms does Sub-Entity wildcarding:
    
    CREATE MCC 0 ALARMS RULE all_circuits -
    	EXPRESSION = (NODE4 foo CIRCUIT * SECONDS SINCE LAST ZEROED)
    
    aud...

Aud,

    You indicate in .-1 that wildcarding of child entities (but not global
    entities) is allowed in Alarm Expressions.  I seem to have a problem in
    that an alarm containing:-

	  EXPRESSION = (CHANGE_OF (NODE4 fred LINE SVA-0 SEND FAILURE,*,*),-
			AT EVERY 1:0:0),-

    works fine for me, but if I replace SVA-0 with *, MCC says

	Valid Entity specifier not found in Alarm Expression.

I am running SSB MCCBMS 1.1, installed from the May CDD rom.
    

    
    Yes, you are correct.  I'm sorry I forgot the caveat.  The
    sub-entity wildcarding only works in COMPARISON and OCCURS
    expressions.  
    
    It will not work for CHANGE_OF expressions.
    
    ALARMS doesn't yet have the smarts to know that this expression:
    
	  EXPRESSION = (CHANGE_OF (NODE4 fred LINE SVA-0 SEND FAILURE,*,*),-
			AT EVERY 1:0:0),-
    
    doesn't mean that:
    
    NODE4 FRED LINE SVA-0 SEND FAILURE = 1 and
    NODE4 FRED LINE SVA-1 SEND FAILURE = 2
    
    determines that a rule has fired.  We don't have the relationship
    between the entity-and-value stored for smart comparison.
    
    This exact problem will be solved when GLOBAL WILDCARDING is introduced.
    
    
    aud...
    
    

Audrey, that one should be qared so we don't lose sight of it.

jill