[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 16: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.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 2782.1 |  | TOOK::GUERTIN | Menagerie Control Center | Fri Apr 17 1992 09:09 | 10 | 
|  |     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.
 |