[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

657.0. "valid entity?" by JETSAM::WOODCOCK () Thu Jan 24 1991 13:31

Hello,

This looks to me to be a valid entity. I'm using the MCS kit. Have 
things changed that much or is this a bug in alarms. I also tried the
new syntax for domain rules (first time I'd seen this) to no avail.

regards,
brad

........................................................................
create mcc 0 alarms rule test1 -
expression=(change_of(node4 bbpk99 circuit syn-0 substate,*,*)),-
procedure=mcc_common:mcc_alarms_mail_alarm.com,-
parameter="decmcc",perceived severity=critical,in domain .pko-24
!
!MCC 0 ALARMS RULE test1 
!AT 24-JAN-1991 09:50:47 
!
!Valid entity specification not found in alarm expression.
!
create mcc 0 alarms rule test1 -
expression=(change_of(node4 .bbpk99 circuit syn-0 substate,*,*)),-
procedure=mcc_common:mcc_alarms_mail_alarm.com,-
parameter="decmcc",perceived severity=critical,in domain .pko-24
!
!MCC 0 ALARMS RULE test1 
!AT 24-JAN-1991 09:51:20 
!
!Valid entity specification not found in alarm expression.
!
exit
!
T.RTitleUserPersonal
Name
DateLines
657.1Is the entity parsed on a SHOW command?TOOK::ORENSTEINThu Jan 24 1991 14:0417
    Hi Brad,
    
    I am not able to reproduce the problem you see.  Yes, this
    does look like a valid entity to me too.
    
    Could you try something on your system for me?
    
    SHOW node4 bbpk99 circuit syn-0 substate
    
    What is the response you see?  ALARMS uses some of the FCL parsing
    routines, but then converts some of the errors to ALARMS errors.
    In using the FCL directly for doing the parsing, you may find the 
    real parsing problem.
    
    Let me know how it goes.
    
    aud...
657.2show works fineJETSAM::WOODCOCKThu Jan 24 1991 14:2917
Hi,

I had tried this before but did a double check. It works fine.

brad...


show node4 bbpk99 circuit syn-0 substate
!
!Node4 24.547 Circuit syn-0 
!AT 24-JAN-1991 11:19:16 Status
!
!                               Substate = Synchronizing
!
exit
!

657.3Try the ALARMS debug logicalTOOK::ORENSTEINThu Jan 24 1991 17:158
    Hmmm, how about this:
    
    $ DEFINE MCC_ALARMS_FM_LOG 10
    
    Now, create the rule and post the results.  I'll be watching.
    
    aud...
    
657.4parse statusJETSAM::WOODCOCKThu Jan 24 1991 17:559
aud,

Here are the results. After the create command I got the following:

parse_status from PAR_ENTITY= 326d02a
PARSE STATUS = 983066

then the valid entity spec error    

657.5Seems like a mismatch to me...TOOK::ORENSTEINThu Jan 24 1991 18:2118
    >>> parse_status from PAR_ENTITY= 326d02a
    	
    The PAR_ENTITY is passing back the status BADVERB.
    
    The only time I have ever seen this was right after
    we installed a new kit, and I was using an old MCC_ALARMS_FM.
    I think there is a mismatch between the version of ALARMS
    and the version of MCC.
    
    What is the date of your MCC_ALARMS_FM?  I believe it should
    be 14-JAN-1991 for the MCS Kit.  What do you see in response
    to the command:
    
    SHOW MCC 0 ALARMS ALL ATTRIBUTES
    
    aud...
                      
    
657.6solved...access not entity probsJETSAM::WOODCOCKThu Jan 24 1991 20:0310
Solved... The major problem is that MCC gave back an inappropriate
message for the error it seems. It dawned on me that I hadn't gone
back and reset protections after the install (you'd think I'd learn
after 20 or so installs :-)). So I did. And it worked.
Somehow MCC gave an invalid entity error where it should have give
an access error.        
    
onward,
brad...

657.7Squashed at sunrise.TOOK::F_MESSINGERThu Jan 24 1991 22:576
    
    This is QARable material.  I can't count the number of times I've be
    bit by that "MM Access Bug" and then only to let it slip thru the
    cracks by not QARing it.  That bug is history...soon to be geography!
    
    Fred  
657.8Why ask why?TOOK::ORENSTEINFri Jan 25 1991 12:544
    Now I'm really curious ... Why did it work from the FCL, but not
    from ALARMS?  
    
    aud...
657.9more detailJETSAM::WOODCOCKFri Jan 25 1991 15:5717
    Now I'm really curious ... Why did it work from the FCL, but not
    from ALARMS?  
    
> When I checked the protection some files were under the USER account
> and some were under SYSTEM. There were alarms files with owner=SYSTEM.
> Speculation... Also, my first pass to changing the protections didn't
> change all the files because MCC was running and wouldn't let me do
> some of them. Interesting enough at this point I retried an alarm
> creation and received the proper ACCESS error. I then shut the system
> down and rebooted not allowing MCC to come up, changed the remaining
> files, and restarted MCC. Success. It appears that a certain set of
> files with a wrong protection set creates the erroneous error, while
> if a different set (or subset) is wrong you receive the proper error.
>

brad...
657.10What about this?TOOK::ORENSTEINFri Jan 25 1991 17:0412
    I gave it some more thought and I don't think the file protections
    were the whole problem.  As you even mentioned, if the file protection
    is not right then you recieve an ACCESS error.
    
    Once you create one ALARM rule, the Parse Table File is in memory and
    ALARMS never goes to the disk again.  So, could you have started up
    ALARMS with an old PTB and then installed a new one?  I still really
    feel that there was a mismatch in the stuff you were running.
    
    In your note 657.9 you did mention that MCC was running...
    
    aud...
657.11not sure..JETSAM::WOODCOCKMon Jan 28 1991 17:4513
    
    Once you create one ALARM rule, the Parse Table File is in memory and
    ALARMS never goes to the disk again.  So, could you have started up
    ALARMS with an old PTB and then installed a new one?  I still really
    feel that there was a mismatch in the stuff you were running.
    
> It's possible but.. I was not actively using the alarms BUT the MCC EVL
> and the HISTORIAN processes *may* have still been running? I don't know
> at this point if they were. But would this explain why after I only 
> changed some file ownerships I began receiving the proper error?
> I tried to reproduce this problem with a reinstall but was unsuccessful.

> brad...
657.12This is too confusing...TOOK::ORENSTEINWed Jan 30 1991 15:3115
    > It's possible but.. I was not actively using the alarms BUT the MCC EVL
    > and the HISTORIAN processes *may* have still been running? I don't know
    > at this point if they were. But would this explain why after I only 
    > changed some file ownerships I began receiving the proper error?
    > I tried to reproduce this problem with a reinstall but was unsuccessful.
    
    
    Hi Brad,
    
    I can't say much without knowing which file protections you changed and
    which protection error message you received.  I think we should punt on
    this topic since it will be hard to figure out exactly what happend on
    the day you had these problems.  Is this OK?
    
    aud...
657.13agreed...lets drop itJETSAM::WOODCOCKWed Jan 30 1991 16:3510
>    I can't say much without knowing which file protections you changed and
>    which protection error message you received.  I think we should punt on
>    this topic since it will be hard to figure out exactly what happend on
>    the day you had these problems.  Is this OK?
    
A punt sounds good to me. I was ready to drop this one a while back. It
didn't seem to warrant the effort unless it bites back again.

cheers,
brad...