Why not set up a monitor in Management Central to test and see of the
SMTP/MSF are running, if not start them, if they don't start in a
reasonable time period put a break message to QSYSOPR/QSYSMSG message
queues. If you use the reverse image on the message it'll grab you as
best as possible.
Unfortunately the increase chair voltage and increase keyboard voltage
commands were rejected by IBM management so those are not part of the
base OS, as much as I would have loved it..... ;-)
Even Brad's software (vastly superior to the base SMTP/MSF in my view)
will need to be monitored to be sure it's running.
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
On 3/18/13 1:39 PM, Mike Krebs wrote:
I use the message every day approach and I've been known to be busy or pre-occupied to notice its absence...but I have also caught things going on when i DID notice that it didn't come through.
Rob's "keep alive" would work if you had a reliable second box that could script the timeout.
And it isn't "base OS", but using something like HTTPAPI given the right web service would let you know something was wrong.
Of course, if you figure out the monitor, it is pretty easy to effect the cure in most cases.
________________________________
From: James H. H. Lampert<jamesl@xxxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
Sent: Monday, March 18, 2013 1:11 PM
Subject: Re: Making a box "scream bloody murder" if certain jobs aren't running -- any ideas?
On 3/18/13 10:37 AM,rob@xxxxxxxxx wrote:
>James,
>
>In theory you could write a sender, and a receiver, for the IBM smtp
>stuff. Send one every x minutes, if the receiver doesn't find it then use
>a sockets program to active that fence charger wired to your chair.
>
>Or, we paid a little for a slightly more full featured account than the
>free ones at yahoo. Our IBM i sends off an email to yahoo, it forwards it
>on to our email receiver (Domino). If the Domino doesn't receive one
>within x minutes all hell breaks loose. My first suggestion doesn't test
>if, for some reason, your sender gets blacklisted, comm drops, etc. The
>second method is a much more robust end-to-end.
Well, I'm more concerned with how to "activ[ate] that fence charger
wired to [my] chair [and the boss's]," or to make "all Hell break loose."
For verification of function, the boss and I are both thinking of
sending a test email as part of the IPL process, after giving TCP, SMTP,
and MSF time to come up, and sending one at a fixed time every day, but
I'm thinking that an alarm is more likely to be noticed than the lack of
a verification.
--
JHHL
--
