Conference csc32::consolemanager

>    My question is more to how it will look from the PCM side.  As I
>    understand it there will need to be an additional Icon on the PCM
>    console to take these messages.  Is that correct?  Or can I guide the
>    message to the icon that reperesents the system with the event?  
    
    You can do either but there are some differences in each.
    
    If you can make ROBOMON send messages to some application then you
    could write the application and then configure a node in the PCM
    config and use a connect type of pseduo-terminal and configure it to
    run your application. The advantage to this is that all your messages
    and events will be logged just as if it were a "real" system
    connected via a terminal server or whatever. You will then configure a
    scan profile that PCM will use to determine if the message is significant
    and if it should signal an event. The disadvantage is that it does
    require a license for a single connection to do this. if the customer
    hasn't already purchased sufficient license units they will have to 
    purchase at least one more.
    
    The other method is to create an application that Robomon will run 
    when it fires a rule. This application will call the PCM API routine
    CMUserSendEvent to send the event to PCM and if ROBOMON provides the
    nodename of the system in it's rule firing then we can fill that in
    the packet that CMUserSendEvent sends to PCM and the approproate
    icon will change color. Note that the nodenames configged in Robomon
    *must* be identical to those in PCM. The point is that it's a case
    sensitive match! The advantage to this method is that it doesn't
    require a license to do this. The disadvantage is that events sent
    via CMUserSendEvent *are not* logged which means you have no audit
    trail and they will not appear in the "Show Events" window in the C3.
    Note however that ENS will receive the text and could pass that to
    other action routines so you could create an action that logs all the
    messages for you.
    
    Regards,
       Dan
    
    Also, I was told that since there was an extra icon that represented the
    need for one more agent license even though there really weren't any
    additional systems (hardware) being monitored.  Is that one correct?
    
    Thanks in advance for the help.  I have read through some other notes
    in this conference and have printed out Chapters 9 and 10 in the PCM
    users guide.
    
    Mike

� The disadvantage is that events sent via CMUserSendEvent *are not* logged
� which means you have no audit trail and they will not appear in the "Show
� Events" window in the C3. 

    I presume that this was the intended behaviour. Is this still the case
    and, if so, what was the reasoning behind this ?

Thanks,
Ross

>>� The disadvantage is that events sent via CMUserSendEvent *are not* logged
>>� which means you have no audit trail and they will not appear in the "Show
>>� Events" window in the C3. 

>    I presume that this was the intended behaviour. Is this still the case
>    and, if so, what was the reasoning behind this ?
    
    Yes, it was intended behavior and it is still the case with 1.6. The
    reason this is this way is because all logging and scanning for events
    is performed by the line controller daemons and when you call
    CMUserSendEvent you are sending an event packet directly to ENS. The
    line controller daemon was bypassed. 
    
    It's pretty simple to make the application that Calls CMUserSendEvent
    log everything that it sends and thats the best you can do at this
    point.  If the behavior of CMUserSendEvent is to change you'll need tro
    make your voice heard to product management.  
    
    Regs,
      Dan

� If the behavior of CMUserSendEvent is to change you'll need to make your
� voice heard to product management. 
    
    Oh... but mine is such a small voice...   :�)

Thanks,
Ross

    If you want a logging of all events, then OSCint provides a History
    function that logs all events to a file, which can then be interrogated
    - obviously, though, this is outside PCM
    
    Thought you may be interested
    
    Shaun