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

Conference csc32::consolemanager

Title:POLYCENTER Console Manager
Notice:Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS:
Moderator:CSC32::BUTTERWORTH
Created:Thu Aug 06 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1541
Total number of notes:6564

1017.0. "Event class and filter matching" by 48332::KUOCH () Mon Oct 02 1995 07:53

Hello,

   I am porting an PCM application from VMS to OSF1 :
   PCM 1.5, OSF1 (Digital UNIX) 2.0

   The flow diagram for filter matching figured in the help is (OSF version) :

              .....          Yes
        Event name match  ? ------------------> System name match ? ---> ....
    		|                  ^                  |
    		| No		   |		      |
    		|		   |		      |
    		V		   |		      V
        Event class match ? -------+		    .....
    		|             Yes
    		| No
    		|
    		V
        Discard event.

   I see that if the event name is matched, PCM continues to verify 
   the fields : system name, group name, susbsystem name and priority,
   but PCM doesn't verify the class name. I run my application, and it
   confirmes this feature. 

   So my question is : Why on OSF1, the class name is not verified if 
   the event name is match ? (My colleague says that it does on OpenVMS)   

   Is there a difference in the filter matching mechanism between OpenVMS
   and OSF ?

   Thank you in advance.
Regards.
Cheu.
   
    
T.RTitleUserPersonal
Name
DateLines
1017.1ZENDIA::DBIGELOWInnovate, Integrate, EvaporateMon Oct 02 1995 10:1915
    First, install the version 1.6 kit. There is also an ECO kit available.
    See note 2 for the kit name and location.
    
>   So my question is : Why on OSF1, the class name is not verified if 
>   the event name is match ? (My colleague says that it does on OpenVMS)   

    Probabily because it would be too confusing. The code is the same on
    VMS as it is on Unix, thus making the behavior the same. 
    
>   Is there a difference in the filter matching mechanism between OpenVMS
>   and OSF ?

    Again, no. It's the same code.
    
    Dave
1017.2Detail explanations. 48332::KUOCHMon Oct 02 1995 14:3256
    I have not explained clearly the problem in my precedent note. That is :

    On Digital UNIX OSF1, I run the Configuration Editor X-Window interface
    with the command 
    	console -e

    Then I define the filter, 

      +------------+  +------------+
      | Event...   |  | Systems... |
      +------------+  +------------+
      +-+	      +-+		+---------------+   +----------------+
      | |All events   | |All system	| Subsystem...  |   | Priorities...  |
      +-+             +-+		+---------------+   +----------------+
      					+-+		    +-+
      +------------+  +------------+	| | All subsystem   | | All priorities
      | Classes... |  | Groups...  |	+-+                 +-+
      +------------+  +------------+
      +-+	      +-+
      | |All Classes  | |All Groups
      +-+             +-+
      
    All are blank, except in "Classes...", I select only "My_Class".
    its event is "My_event".

    So logically, my application must reveice only an event whose class is 
    "My_class". 

    But in reality, it receives also other classes, if the event name is 
    "My_event".

    The scenario is :

    On the first time, PCM dispathes the event ("My_Class", "My_event")
    to my application. After processing, my applications sends an event
    to PCM using API CMUserSendEvent ("Another_class", "My_event"),
    note that only the class name is changed, event name and other fields
    are not changed (for the reason of event maintenance).

    PCM receives the event whose class is "Another_class", but PCM sends
    it again to my application, even if the class is not "My_class".
    So the event is exchanged infinitly between PCM and my application.

    This is because PCM first verify the event name, in stead of class name,
    if the event name is found, PCM verify other fields, not the class name.

    May an event have two classes ?
    Have I made a mistake while configuring the filter ?

    (My colleague working for the same application on VMS, he says that
     PCM/VMS tests the class "Another_class" and it doesn't send it again
     to the application.)

Regards.
Cheu.  
    
1017.3ZENDIA::DBIGELOWInnovate, Integrate, EvaporateTue Oct 03 1995 12:0319
    >May an event have two classes ?
    
    Yes.
    
    Have I made a mistake while configuring the filter ?
    
    It doesn't appear so. My guess is that there is a bug in the
    CMUserSendEvent() call and that it is ignoring the class name.
    ENS then gets the event and looks up what class the event is associated
    with, sees that is is associated with your calss and then dispatches 
    it to your action routine.
    
    As a work-around, you might have to check the class yourself and if
    it's not in your defined class, then you can ignore it. The only
    problem with this is that you will have to hard code the class names
    that you are interested in.  I will put this on the list for the 
    support team to have a look at.
    
    Dave
1017.4Collegue is confusing ... Is it a joke ?48579::MALRASKnowledge is power, en France aussiFri Oct 06 1995 06:5912
Re .1

Sorry, i'm not confusing !!!

On VMS(VAX or AXP) it worked with CM 1.5.

Now, it seems working on DEC Unix with PCM 1.6 + ECO01

You said "same code" ... gosh !!!

Regards.
JF
1017.5CSC32::BUTTERWORTHGun Control is a steady hand.Mon Oct 09 1995 12:4914
    As Dave saud. It's the same code. What the basenoter reported is
    *EXACTLY* what I would have expected to happen. Here is some pseudo
    code to show how filtering works:
    
    IF ((EVENT .OR. CLASS) .AND. (SYSTEM .OR. GROUP) .AND. SUBSYSTEM .AND.
    PRIORITY) THEN  do whatever.
    
    The key here is that event is logically OR'd with class so if the event
    in questions meets *EITHER* of these criteria then it will be passed
    to the next decision - this is the way it works on all platforms -
    period the end.
    
    Regs,
      Dan