Hi Brad,
The only way I know of,  to add more variables to an event over and above
the varbinds initially copied from the trap (as per the AlertMap) is with
an Event Procedure.

Let's say your current event code - the one  the trap's mapped to in the
AlertMap - is 0x12345678.  Make a copy of that event using the Event Config
Editor - say to custom event code 0xfff01000.  Let's suppose the extra attr
you want to grab from the device model is 0x12345.  Here's a replacement
(or override ) definition to put in your custom EventDisp
($SPECROOT/custom/Events/EventDisp)  for event 0x12345678 which will add
the attr as event var 99 (could be any number) and feed new event
0xfff01000 into the system...
===
0x12345678 P " \
CreateEventWithVariables( \
   { C CURRENT_MODEL }, \
   { H 0xfff01000 }, \
   SetEventVariable( \
      GetEventVariableList(), \
      { U 99 }, \
      ReadAttribute( { C CURRENT_MODEL }, { H 0x12345 } ) \
   ) \
)"
====
With the ECE, in the event text  for the new 0xfff01000 event you can now
refer to your newly-included var 99, remembering to use the correct type
denotation -   { S 99 } if it's a string etc.
Because you're now doing hard-core event config via the back-end, i.e. the
files, rather than via the ECE UI, you have to trigger the VNM ->
Spectroserver Control to re-read its alert and event config  - I expect you
know that.  Plus  I suggest having EventDisp error logging turned on  by
running your SS with the following turned on in your .vnmrc file:

event_disp_error_file=EVENT_DISP_ERRORS.OUT

so whenever you trigger the VNM to re-read it's event config any mess-ups
will show up immediately  in that logfile (in the SS dir)!

You mentioned the dynamic alarm title - you could develop your Ev proc to
embed your attribute into a friendly string and then put the whole lot into
var 76620  instead but I think you lose flexibility with that approach as
you can't tweak it via the front-end with the ECE.

Also do not save a change to *any aspect* of the event 0x12345678
afterwards using the ECE or it will corrupt the Event proc part of it.
(Spectrum bug).

CA quietly dropped the Event Procedures chapter from the Event Config User
Guide in Spectrum 9.3  - you have to go back to 9.2.x - but even that was
hardly a thorough treatment of the topic!  But I find the occasional use of
them essential.


Good luck!

Cheers
Dan.

*Dan White*
Senior Consultant
Service Assurance
[image: Devoteam]

 *Mob. : *+44 (0)7973 533671
 dan.wh...@devoteam.com

Follow us : [image: Linked In]
<http://www.linkedin.com/company/4160?trk=null> [image: Twitter]
<http://twitter.com/#!/devoteam> [image: Youtube]
<http://www.youtube.com/user/devoteam>

CONNECTING BUSINESS & TECHNOLOGY


On 28 July 2014 16:00, Chandler, Bradford <brad.chand...@libertymutual.com>
wrote:

> Hello;
>
> I know this is possible as I remember I've seen posts about it, including
> on the communities' site in support, but I can't find the link to an
> example showing how to do it?  I think it is an event procedure that has to
> be run, but if there's a way to do it without a procedure, that is ok w/ me
> as well.
>
> Essentially, we have a trap that isn't giving much info when it is sent.
>  More info is available in one of the device's attribute that we'd like to
> include in the event.  We can include it either in the varbind section of
> the trap or in the dynamic title of the PCause if necessary, but I can't
> find how to do it.
>
> I see this one in the Communities, but then I couldn't traverse the new
> environment to check either the "official documents" or the wiki as
> Christian suggests to find it:
>
> https://communities.ca.com/message/13320883#13320883
>
> Thanks for any help.
>
> Brad
>
>
> ---
> To unsubscribe from spectrum, send email to lists...@unc.edu with the
> body: unsubscribe spectrum dan.wh...@devoteam.com
>

---
To unsubscribe from spectrum, send email to lists...@unc.edu with the body: 
unsubscribe spectrum arch...@mail-archive.com

Reply via email to