[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2782.0. "MCC-E_NO_PARENT creating an ALARM" by CSC32::WOESTEMEYER (Why??...Why not!!!) Thu Apr 16 1992 20:22

SYMPTOM:
--------
 After upgrading to VMS V5.4-2 customer trying to create an Alarms
 Rule, following error is returned:

MCC> do sys$sysdevice:[blackwelld]nysb.com

MCC 0 ALARMS RULE NYSB_TRANSLAN_STATUS 
AT 17-APR-1991 11:42:28 

Software logic error detected
                      MCC Routine Error = %MCC-E-NOPARENT,  parent entity does 
                                          not exist 

ANALYSIS:
---------
Verified that the rule itself was valid, that the entity, in this case a 
Translan Bridge, was registered and that 'Show's againest the entity for 
for the alarm rule attribute worked.   Also to verify that it was not a
Translan_AM problem, tried to create a rule againest a node4, same error.

SOLUTION:
---------
Since I knew the customer already had alarm rules set up, I tried to extract
them:

<MOZART_URANUS::>r sys$system:mcc_alarms_extract_rules

MCC_ALARMS_EXTRACT_RULES
  - Generating a Procedure to Rebuild the Alarms MIR
  - Output File: MCC_ALARMS_RULES.COM

>>> EXIT - Alarms MIR is empty; No Rules extracted

!!! Mesaage that alarms MIR was empty made no sense

Directory SYS$COMMON:[MCC]

MCC_ALARMS_ATTRIBUTE_MIR.DAT;1
                        141  18-NOV-1991 10:54:16.64
MCC_ALARMS_INSTANCE_MIR.DAT;1
                         66  18-NOV-1991 10:54:15.19

!!! looked at system time

<MOZART_URANUS::>sh time

  17-APR-1991 14:25:55

!!! set correct system time, since it was even before file creation date
!!!After setting the system time to the correct date, alarm rules could be 
!!!created again and existing alarms could be listed.

MCC> do sys$sysdevice:[blackwelld]dec_alarm_test.com

MCC 0 ALARMS RULE test 
AT 16-APR-1992 14:30:57 

Entity created successfully.


MCC> sho  mcc 0 alarm rule nysb_translan_status all char, in domain usa

MCC 0 ALARMS RULE nysb_translan_status 
AT 16-APR-1992 14:33:20 Characteristics

Examination of attributes shows:
                              Procedure = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_ALARM.

                                          COM;2
                      Exception Handler = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_EXCEPT

                                          ION.COM;2
                            Description = "If LINE 1 (LAN PORT 0) is anything 
                                          other than FORWARDING , then          

                                                        either there is a 
                                          problem with the TRANSLAN or the      

                                                           circuit is in the 
                                          non-forwarding state."
                               Category = "TRANSLAN problems"
                                  Queue = "MCC$BATCH"
                              Parameter = "@USER.DIS"
                             Expression = (CHANGE_OF(TRANSLAN .nysb LINE 1 
                                          MODULE STATE, FORWARDING,*),          

                                                      AT EVERY 00:01:00)
                     Perceived Severity = critical

------------------------------------------------------------------------------

Now the real question, since the problems seems to be that the system time was 
even before the file creation dates of the alarms MIRs where does the NO_PARENT
error come from???
T.RTitleUserPersonal
Name
DateLines
2782.1TOOK::GUERTINMenagerie Control CenterFri Apr 17 1992 13:0910
    First of all good for you for you for noticing that the system time was
    the root of your problems.  Since the MIR routines which alarms uses
    are time sensitive, having the system time set incorrectly can have odd
    affects.  Especially, if the system time is set to the past, such that
    a request for the current time will end up returning a past time. To
    the MIR, this looks as though the data is in the future. No Parent is
    probably saying that the parent entity of the alarm rule (which was
    probably created some time in 1992) does not exist (yet).
    
    -Matt.