|
Hi JeffBRMS control group statements:
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 ?
- By my reckoning QUSRSYS will get saved via SWA. Is this going to beDon't know about recovery scenarios. The BRMS log has:
OK in a recovery scenario ? My experience is not good using SWA on
QUSRSYS.
On Tue, Jan 22, 2013 at 5:24 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:
All,is
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
save while active. The entire control group took 90 minutes. Theimprovement
restricted state portion took about 18 minutes. This is a vast
over what I'm currently doing, which is everything in restricted state,take
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
an additional 21 minutes, bringing it up to 39 minutes. That's a lotif
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
prettywe 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
thequick since the system was still very close to restricted) and kick off
prettystartup 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
underwell (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
youapplicable 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,
ofare hereby notified that any use, disclosure, dissemination, or copying
listthis 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
--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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.