I'm trying to figure out how I can include specific attributes in my AlarmNotifier SetScript. Particularly today, i'm trying to figure out how i can get TopologyModelNameString into the SetScript so that i can perform some logic against it (so putting it into a variable within the script would be enough) and/or include it in external system calls from within the SetScript so that the data gets passed over to the other system.
My research has gotten me to EXTRA_ATTRS_AS_ENVVARS, but I'm not really sure where to go from there.
Ask and ye shall inevitably find. Found this: Tuesday Tip: How to add SPECTRUM attributes to alarm notifications. Reading now, will post success/failure/results.
There is a good example in the Docs:
Passing CA Spectrum Attributes to Scripts - CA Spectrum - 10.1 and 10.1.1 - CA Technologies Documentation
Hope this helps.
Thanks Bill_Wol4th. Between those two sets of documents I think i'm off to the races. Initial result is not encouraging though. I've added the following line to my .alarmrc (or at least i think it's the right .alarmrc file):
And added the following line to my SetScript in the echo_info() function:
echo "TopologyModelName:" $SANM_0x129e7
I'm getting the following in my NOTIFIER.OUT:
I went to the .alarmrc file located in the ALARMNOTIFIER.idb file:
So, i'm editing $SPECROOT/custom/Notifier/.alarmrc. Do i need some kind of restart to suck in the new .alarmrc config?
Just noticed this:
Note that Windows will automatically set environmental variables to uppercase, therefore when you reference these variables you must be sure to use the uppercase format (e.g.:$SANM_0X100C5).
Updated my reference in the SetScript to be this:
echo "TopologyModelName:" $SANM_0X129E7
But still not getting the value echoed into NOTIFIER.OUT.
Did you use all upper case for the attribute in the .alarmrc as well? I think it needs to be.
And anytime you make a change to the .alarmrc you need to cycle the Notifier process…
Ah, i think this is the key. So, i'd just use task manager to kill the process then start it up using the method described here: Start AlarmNotifier through process daemon, yeah? Since i have this line in my .alarmrc:
That would cause all my currently open alarms that fit my SANM policy filter to be re-executed against the SetScript. Is that right?
Actually, if you have set up an AlarmNotifier.idb and you have the autorestart set to yes, when you kill Notifier processd will start it back up for you automatically. If you haven’t configured the idb file then yes, using the launchinstdbapp utility will work.
Hope that helps
And yes, if you have the GET_EXISTING_ALARMS=true that will reprocess all existing alarms when the notifier restarts…