Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Tom's alarmprogram sent hundreds or thousands of 'resource overflow: Locks' emails when the server ran out of locks. Murray Wood suggested coding the alarm script to suppress repeats, e.g. a lock file with a five-minute timestamp. Art S. Kagel recommended his eventalarm.c in the IIUG repository's utils3_ak package, which throttles per event id. Tom thanked him.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hello All
We have alarmprogram turned on but unfortunately, when the Server runs
out of locks we recieve hundreds or even thousands of emails stating
so - " Attention! : Dynamic Server resource overflow: 'Locks'."
Is there a way to configure the alarm so that we get a limited number -
say 10 or 50 emails rather than an email for each of the sessions and
the locks that are overflowing?
Thanks in Advance!
Tom
Alarmprogram gets processed for each error as listed in the Informix
messages file.
If you do not want all the errors then you need to code alarmprogram not to
send you these emails. Something like touch a file (alarmlock) and if the
timestamp is in the last 5 minutes not send another email .... OR create
the file and submit a job to delete that file in 5 minutes while not sending
an email when that file exists.
MW
-----Original Message-----
From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org]
On Behalf Of tomcaml@yahoo.com
Sent: Thursday, 3 August 2006 9:04 a.m.
To: informix-list@iiug.org
Subject: Alarmprogram & Dynamic Server resource overflow:Locks
Hello All
We have alarmprogram turned on but unfortunately, when the Server runs
out of locks we recieve hundreds or even thousands of emails stating
so - " Attention! : Dynamic Server resource overflow: 'Locks'."
Is there a way to configure the alarm so that we get a limited number -
say 10 or 50 emails rather than an email for each of the sessions and
the locks that are overflowing?
Thanks in Advance!
Tom
_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
↪ replying to tomcaml@yahoo.com
Art S. Kagel — — source: Usenet: comp.databases.informix
tomcaml@yahoo.com wrote:
> Hello All
>
> We have alarmprogram turned on but unfortunately, when the Server runs
> out of locks we recieve hundreds or even thousands of emails stating
> so - " Attention! : Dynamic Server resource overflow: 'Locks'."
>
> Is there a way to configure the alarm so that we get a limited number -
> say 10 or 50 emails rather than an email for each of the sessions and
> the locks that are overflowing?
Take a look at my alarm program, eventalarm.c, in the package utils3_ak in
the IIUG Software Repository. Basically it avoids this problem by making a
record in a file of the last time it sent a message about a particular event
id and only sends another email after N minutes have passed (N is
configurable but defaults to 5 minutes)
Art S. Kagel
Gracias!!!!
Art S. Kagel wrote:
> tomcaml@yahoo.com wrote:
> > Hello All
> >
> > We have alarmprogram turned on but unfortunately, when the Server runs
> > out of locks we recieve hundreds or even thousands of emails stating
> > so - " Attention! : Dynamic Server resource overflow: 'Locks'."
> >
> > Is there a way to configure the alarm so that we get a limited number -
> > say 10 or 50 emails rather than an email for each of the sessions and
> > the locks that are overflowing?
>
> Take a look at my alarm program, eventalarm.c, in the package utils3_ak in
> the IIUG Software Repository. Basically it avoids this problem by making a
> record in a file of the last time it sent a message about a particular event
> id and only sends another email after N minutes have passed (N is
> configurable but defaults to 5 minutes)
>
> Art S. Kagel
Your privacy choices
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.