Zugg Software :: View topic - Problem using variable as alarm description

Newbie Joined: 04 Jan 2002 Posts: 5 Location: Albania

Howdy, Just wanna take this line to say: Thanks zugg, zmud kicks ass.

Anyway, I work in a NOC now (not much time for mudding) and one of my duties is to pull
packet statistics from the routers of our
customers by manually telnetting into them
and typing various commands. A perfect Zmud
application, I quickly realized. The script
went rather quickly, I got it to step
through a text file of hostnames,
telnetting, logging to file, etc, and I
started tweaking it to make it neater and
more configurable.

So, I thought, "Hey, why not configurable
stat pull times? I'll just use dynamically
set alarms read from text files like I do
the router hostnames!"

Well, Zmud had other ideas.
You'd think that

#ALARM <@ALARMTIME> {STARTSTATPULL}

would work, provided @ALARMTIME was set to
some suitable time. Well, it doesn't,
instead of 07:00:00 as an alarm pattern,
I get <@ALARMTIME>. Hmm.. well, I was
toying with it and reading the forums when I
learned about the alarm description field,
so I tried that,

#ALARM "AlarmOne" <@ALARMTIME> {STARTSTATPULL}.

Funny, that works, only I've got to generate
X number of alarms, so I can't use the same
descriptor for all of them or else they'd
just overwrite. So, I tried

#ALARM "@ALARMNUMBER" <@ALARMTIME> {STARTSTATPULL}.

What do I get in the descriptor field of the
alarm trigger?

@ALARMNUMBER.

I try enclosing it in < >, and I get
<@ALARMNUMBER> in the field. (Btw,
@ALARMNUMBER is the variable that is used to
step through the text file as it dynamically
generates the alarms, I thought I'd use it
since it was unique in these instances.)

Does anybody know the correct syntax for what
I'm trying to do?

*SCREEECH*

Novice Joined: 20 Dec 2001 Posts: 39 Location: USA

quote:
#ALARM <@ALARMTIME> {STARTSTATPULL}

would work, provided @ALARMTIME was set to
some suitable time. Well, it doesn't,
instead of 07:00:00 as an alarm pattern,
I get <@ALARMTIME>. Hmm.. well, I was
toying with it and reading the forums when I
learned about the alarm description field,
so I tried that,

I've never used this, so this is a guess... but you might want to look at the
%expand function... I think you might try something like this:

#ALARM <%expand(@ALARMTIME,1)> {STARTSTATPULL}

Bob, aka Kayd on SWMud and a few others.

Newbie Joined: 04 Jan 2002 Posts: 5 Location: Albania

Hmmm.. nope, thanks for pointing out that
function though.

I have my settings set to expand variables,
so I don't think that's the problem.
The problem is twofold, Zmud seems to have
been programmed specifically to annoy me.
Setting the #ALARM dynamically is impossible
without the description (an undocumented
feature), and I can't dynamically set multiple
alarms without a variable in the descriptor
field, and that doesn't like to expand variables.
(Well, with my particular style of coding)
Oh well, I suppose I'll have to abandon my
minimalist style and program each alarm
manually, even though it heartily offends my
sensibilities.

*SCREEECH*

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Do you need more than one alarm running at the same time, or would just one alarm that you change it's pattern when you need it do? Maybe you should also look into temporary alarms.

You can't re-define an existing alarm without using an ID because you can have as many alarms as you want, and if you do not specify an ID, the default action of the #ALARM command is to create a new alarm.

Kjata

Novice Joined: 29 May 2001 Posts: 48 Location: USA

I don't know what to tell you, I really don't think Zmud was meant for such tasks. More of a user to mudd emulation package.

No offense but it sounds borderline hacker stuff.

Newbie Joined: 04 Jan 2002 Posts: 5 Location: Albania

>Do you need more than one alarm running at
>the same time, or would just one alarm that
>you change it's pattern when you need it to?

I'm attempting to design this script to run
24/7, reading alarm times periodically from
file. I suppose I could use one alarm with
a shifting time, but it'd be tricky to fix it
so that it ran fine when the stat pull time
list changed.

>Maybe you should also look into temporary >alarms.

>You can't re-define an existing alarm >without using an ID because you can have as >many alarms as you want, and if you do not >specify an ID, the default action of the >#ALARM command is to create a new alarm.

Yup, that's why I say I can't dynamically
generate alarms, 'cos after a while they'd
pile up. I could just specify the class and
erase the whole class every time I read the
stat pull time list...
That might work. I came up with a temporary,
if inelegant, solution, limiting the number
of stat pull times to 8 and manually setting
each alarm, 1-8, based on the text file.

>I don't know what to tell you, I really >don't think Zmud was meant for such tasks. >More of a user to mudd emulation package.

Yeah, but I was hard pressed to find a
telnet client with a powerful yet easy
scripting language. I suppose I could dig
up an old copy of telix and use SALT, but I
already know Zmud :P

>No offense but it sounds borderline hacker >stuff.

Offense? Dear god man, I take it as a
compliment. Hackers are those that attempt
to get more out of things than they're
designed for, nothing bad in that.

Hehe, I'll post the script when I'm done with
it, of course, that may be some time :p.

Oh, one other thing, I just realized that
even thought the alarm pattern is @ALARM,
it still uses the value in the variable!
Pretty wacky, huh? My inelegant solution
was to create a numbered variable for each
stat pull time entered, ALARM1, ALARM2, etc,
and stopping when it hit the end of the list
(#VAR ALARM4 {%read(3,4)};#IF {@ALARM4 <> END}, etc. etc.).

*SCREEECH*

GURU Joined: 10 Oct 2000 Posts: 1116 Location: USA

Can you give me an example of the txt file you're pulling in for the alarms? You could still dynamically create alarms, but it'd take some finesse. I'll try to play around with it when you give me some examples :)

Iljhar

Newbie Joined: 04 Jan 2002 Posts: 5 Location: Albania

statpulltime.txt:

04:00:00
08:00:00
12:00:00
16:00:00
20:00:00
00:00:00
END

Real simple, I got three like this, one for the
site router hostnames, one for the command list
to be executed at each router, and the alarm
list. The "END" line I use to test and see if
it's done with all the info lines.

Thank you for your help!

*SCREEECH*

SubAdmin Joined: 18 Nov 2001 Posts: 5182

You are quite right ALARM just isn't happy with that configuration. It holds its argument almost verbatim. There is however a way around this maybe two ways if you like creativity.

The first way is to store your statpulltimes file in a list. My list for testing was this:
#VAR meat "1000|2000|3000|4000"
Next you have to get that list into the alarms:
#FORALL @meat {#EXEC %expand(#ALARM {%i} {do something})}

Of course you could always skip the list:
#EXEC %expand(#ALARM {@ALARMTIME} {STARTSTATPULL})

Newbie Joined: 04 Jan 2002 Posts: 5 Location: Albania

#EXEC %expand(#ALARM {@ALARMTIME} {STARTSTATPULL}) works!!!
Whoohoo!

Except it doesn't like alarm descriptors at all, even static ones!
No matter. I'll just manage them by class.

<a few hours pass>

Okay, I'm done. Here's the command that's run at the top of every five minutes.

#FILE 3 "statpulltimes.lst"
#DELCLASS ALARMS
#CLASS ALARMS
#VARIABLE ALARM {%read(3,1)}
#WHILE {@ALARM <> END} {#EXEC %expand{#ALARM {@ALARM} {START} ALARMS};#AD ALARMCOUNT 1;#VAR ALARM {%read(3,@ALARMCOUNT)}}
#IF {@ALARM = END} {#VAR ALARMCOUNT 1;#VAR ALARM 0;#CLOSE 3}

Thank you so much for your help!
I'm still tweaking the script, otherwise I'd post it. Gimme a few hours.

*SCREEECH*