All,
A couple of weeks ago we had a day long power outage (another thread). The
actual outage started while the system was in restricted state, meaning my
power handling program was not running. Fortunately for us, the last item
of the save got done just prior to QUPSDLYTIM of 1200.
I had a couple of things to work on, including the power handling program,
QUPSDLYTIM, and what to do about power handling during restricted state,
since the power handling program is not running at that time. I had
several suggestions from many people on this list which I truly appreciate.
I decided to look at all of it as a whole from a "what do we want from a
business perspective?" instead of looking at the individual pieces in a
vacuum.
I was already doing a *SAVSYS 3 days a week and had been contemplating
doing it 5 days a week. I have 2 BRMS control groups where the only
difference is the *SAVSYS. The control group with the *SAVSYS takes only 5
minutes or so longer. Yes I know this is overkill for *SAVSYS but humor
me. I want a full lock, stock, and barrel backup every day. As I said,
humor me.
I have made a couple of tweaks to the power handling program as well as
isolated it to it's own library, UPSLIB. I also put the QUPSMSGQ UPSCTL in
this library. I can then back this library up as an individual item if I
want.
The UPSDLYTIM system value is set to 1200 (20 minutes) which means the OS
will shut the system down after 20 minutes of outage, whether I have a
power handling program or not. I toyed with the idea of changing it to
*NOMAX while the power handling program was running, and, whenever it
ended, change back to 1200. Ultimately I decided not to do that because of
the following reasons: 1) we have 30-35 minutes battery available on the
UPS, 2) the power handling program starts an orderly shutdown of the system
13.5 minutes into an outage, and 3) that QUPSDLYTIM of 1200 could save my
bacon if the power handling program fubars. (Not that I ever write faulty
code. <g>)
For backup, this is the current BRMS control group in question (does not
currently do save while active):
10 *EXIT *DFTACT
20 *EXIT *DFTACT
30 *SAVSYS *DFTACT
40 *IBM *DFTACT *YES *NO
50 *ALLUSR *SYSBAS *DFTACT *YES *NO
60 QMPGDATA *SYSBAS *DFTACT *YES *NO
70 *ALLDLO *DFTACT *YES *NO
80 *LINK *ALLAVL *DFTACT *YES *NO
90 ALLSPLF *SPL *DFTACT
100 *EXIT *DFTACT
110 *EXIT *DFTACT
Instead of a break handling program to monitor the QUPSMSGQ during the
backup, I'm thinking of doing the *SAVSYS portion in restricted state, put
in some kind of *EXIT to bring the system back, then back up everything
else as save while active, which means the system would be available to
users and customers sooner. I read in "Backup Recovery and Media Services
for OS/400: A Practical Approach" (PDF available here:
http://www.redbooks.ibm.com/abstracts/sg244840.html) that save while active
is strongly discouraged with *ALLUSR. The last update to this redbook was
2003, so I'm wondering if that's changed. Anyone doing *ALLUSR save while
active?
Another thought I had was to put the *SAVSYS in one control group
(restricted state), everything else in another control group (not
restricted), and run them back to back. This might be trickier, though, as
the first control group has to finish before the next one starts. I don't
know if BRMS has that built in or not. Just thought of that idea while
writing. Also, since I want everything on a single tape, I need to make
sure the 2nd control group doesn't clear the tape.
Suggestions welcome.
(Note: around 5pm, a clerk runs a different control group that DOES do a
save while active on *ALLUSR interactively, with no issues. This
particular save is an incremental save instead of a full save. Don't know
whether full vs incremental would make a difference.)
midrange.com
