MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2013

Re: BRMS - full save with least amount of restricted time



fixed

Responses inline.


On Mon, Jan 21, 2013 at 1:38 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:

Hi Jeff

thanks for sharing, I'm following this with some interest.

2 questions:

- You say all the rest are save while active - what kind of save while
active are you doing ? What is the sync type ? Are you using a message
queue monitor to restart normal processing ?


BRMS control group statements:

*IBM *DFTACT *YES *LIB BACKUPS *NONE
*ALLUSR *SYSBAS *DFTACT *YES *LIB BACKUPS *NONE

Sync type *LIB. I'm not doing any message queue monitoring. Message queue
BACKUPS is in QUSRSYS.



- By my reckoning QUSRSYS will get saved via SWA. Is this going to be
OK in a recovery scenario ? My experience is not good using SWA on
QUSRSYS.


Don't know about recovery scenarios. The BRMS log has:

1/19/13 7:25:50 CPC3701 20 2137 objects saved from library QUSRSYS.

with no mention of any unsaved objects.




On Tue, Jan 22, 2013 at 5:24 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:
All,

I tested this BRMS control group on Saturday:

10 *EXIT *DFTACT
20 *EXIT *DFTACT
30 *SAVSYS *DFTACT
40 UPSLIB *SYSBAS *DFTACT *YES *NO
50 QMPGDATA *SYSBAS *DFTACT *YES *NO
60 *EXIT *DFTACT
70 *IBM *DFTACT *YES *LIB
80 *ALLUSR *SYSBAS *DFTACT *YES *LIB
90 *ALLDLO *DFTACT *YES *YES
100 *LINK *ALLAVL *DFTACT *YES *YES
110 ALLSPLF *SPL *DFTACT
120 *EXIT *DFTACT
130 *EXIT *DFTACT

The *EXIT at sequence 60 returns the system to a normal state via CL
program starting the controlling subsystem and waiting on a data queue
entry from the QSTRUP program before proceeding. Everything after that
is
save while active. The entire control group took 90 minutes. The
restricted state portion took about 18 minutes. This is a vast
improvement
over what I'm currently doing, which is everything in restricted state,
which takes about 75 minutes.

*BUT* the *LINK backup had 49 objects not saved because they were in use.
These were:

/Bytware/StandGuard/AV/logs/avsvr.log (1 object, a log file)
/FAXD01/RCVFAX/00000001.FAX. (1 object)
/QIBM/UserData/HTTPA/admin/logs/error_log.Q113011900 (1 object)
/QIBM/UserData/OS/OSGi (40 objects in this directory or a subdirectory)
/QIBM/UserData/OS400/MGTC (4 objects in this directory or a subdirectory)
/easy400apc/logs/access_log.Q113011900 (1 object)
/easy400apc/logs/basic_error_log.Q113011900 (1 object)

I have a feeling that trying to figure out a way to do these 49 objects
save while active would/will be an exercise in futility.

If I were to move the *LINK to run before restarting the controlling
subsystem, the rearranged control group would look like this:

10 *EXIT *DFTACT
20 *EXIT *DFTACT
30 *SAVSYS *DFTACT
40 UPSLIB *SYSBAS *DFTACT *YES *NO
50 QMPGDATA *SYSBAS *DFTACT *YES *NO
60 *LINK *ALLAVL *DFTACT *YES *NO
70 *EXIT *DFTACT
80 *IBM *DFTACT *YES *LIB
90 *ALLUSR *SYSBAS *DFTACT *YES *LIB
100 *ALLDLO *DFTACT *YES *YES
110 ALLSPLF *SPL *DFTACT
120 *EXIT *DFTACT
130 *EXIT *DFTACT

Based on the timings for each step, the restricted state portion would
take
an additional 21 minutes, bringing it up to 39 minutes. That's a lot
better than the current 75 minutes, but double the 18 minutes I saw.

If anyone is getting a complete *LINK save while active, I'd love to hear
about it.

Thanks.


On Fri, Jan 11, 2013 at 11:23 AM, Jeffrey Carey <Jeffrey.Carey@xxxxxxx
wrote:

We did a full save with minimal down time like so if I recall correctly:

1) Take the system to restricted state
2) Control group changes startup program to *NONE, does the SAVSYS. We
also had it do LINK and DLO (DLO always gave us a few objects not saved
if
we didn't do it restricted) and I think *IBM.
3) Control group starts a subsystem, submits job to monitor for SWA sync
and kicks off SWA of ALLUSR
4) The MONSWA program would wait for the SWA sync point (which was
pretty
quick since the system was still very close to restricted) and kick off
the
startup program and change the QSYSSTRUPGM back to what it should be.

It's been a while since we did that (previous shop), but it worked
pretty
well (especially since it replaced GO SAVE 21!)







Jeff Carey, MSIT, MBA
Sr. Systems Administrator



This communication, including any attachments, may contain information
that is confidential and may be privileged and exempt from disclosure
under
applicable law. It is intended solely for the use of the individual or
entity to which it is addressed. If you are not the intended recipient,
you
are hereby notified that any use, disclosure, dissemination, or copying
of
this communication is strictly prohibited. If you have received this
communication in error, please notify the sender. Thank you for your
cooperation.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

--

Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.









Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact