Conference azur::mcc

	The answer is "No".

	The existing set of Alarms Rule expression formats allows to 
	specify only attributes and events as an argument of an expression. 

	It does not allow an argument (Recording state) of a particular 
	directive (Show Recording) to be a part of expression.
 
     Sam
    

    
    	I think this would be a nice feature to add so that customers
    	can monitor the status of record and export instances.  Perhaps
    	MCC could generate some kind of configuration event from the
        historian when an instance is suspended or resumed.  
    
    	Ted.

	Ted,

 The only situation when recording request is automatically  suspended is 
 when the target entity is deregistered. In this case Historian generates 
 an "Operation Stopped" event (you can find it under MCC 0 Historian_FM entity).
 All other situations when recording request changes its state are predictable
 as a result of Record or Resume/Suspend Recording directives.

 Do you think that Historian should generate an event every time when the
 recording request changes its state even if this is a result of user's action?

	SAm
    

The answer is "Yes". Using either the script AM or data collector with a little
dcl you can accomplish this task. I was just looking at the SCRIPT AM when this
note appeared and I just *had* to try to solve this situation with it. So as a
matter of exercise I wrote a quick script to return the RECORDing state for a
specific entity, created a quick ms file and put it into the dictionary, this 
is now returned as an output:

............................................................................
MCC> show mcc 0 script check_records z record state

MCC 0 SCRIPT check_records Node4 NOCMAN_NS:.BBPK01 Circuit SYN-0
AT 11-SEP-1992 13:00:02 Status

                           Record State = "ACTIVE"
.............................................................................

I then wrote an alarm rule with:

expression=(mcc 0 script check_records z record state=ACTIVE)

enabled it, and presto:

...............................................................................
From:   NOCMAN::DECMCC
To:      DECMCC
CC:
Subj:   Notification of alarm " MCC 0 ALARMS RULE check_records  11-SEP-1992 13:
03:55.26"

     Rule name:   MCC 0 ALARMS RULE check_records
Managed Object:   MCC 0 SCRIPT check_records Node4 NOCMAN_NS
                    :.BBPK01 Circuit SYN-0
   Detected at:   11-SEP-1992 13:03:55.26
      Severity:   Indeterminate

    Expression:   (mcc 0 script check_records z record state=ACTIVE)
         Data:    Rule fired: MCC 0 SCRIPT check_records Nod
                    e4 NOCMAN_NS:.BBPK01 Circuit SYN-0  Record State = ACTIVE 11
                    -SEP-1992 13:03:54.97
  Event Arguments:
..............................................................................

While going thru this exercise I found that my RECORD states are ACTIVE even
though I haven't had a background job in a month on this system. So I agree 
with SAm in the point that the RECORD state doesn't tell you much anymore and 
probably isn't worth looking at. Maybe ensuring the background job is running 
and the LAST SUCCESSFUL POLL is within a reasonable timeframe would be what 
you're looking for. FWIW, since going to V1.2 a few months ago we have had 
ZERO problems on a couple of hundred RECORDings in the production environment.

kind regards,
brad...