× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. January 2013

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

OK, I did my final test yesterday morning and this is what I ended up with
as a BRMS control group (this probably won't format well):

10 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*BEFORE)
20 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*ATSTART)
30 *SAVSYS *DFTACT
40 UPSLIB *SYSBAS *DFTACT *YES *NO
50 QMPGDATA *SYSBAS *DFTACT *YES *NO
60 *EXIT BKPRSTNRM
70 *IBM *DFTACT *YES *LIB BACKUPS *NONE
80 *ALLUSR *SYSBAS *DFTACT *YES *LIB BACKUPS *NONE
90 *ALLDLO *DFTACT *YES *YES
100 *EXIT ENDSBS SBS(QHTTPSVR) DELAY(60) ENDSBSOPT(*NOJOBLOG)
110 *LINK *ALLAVL *DFTACT *YES *YES BACKUPS *NONE
120 *EXIT STRSBS SBSD(QHTTPSVR/QHTTPSVR)
130 *EXIT STRTCPSVR SERVER(*HTTP) HTTPSVR(*ALL)
140 ALLSPLF *SPL *DFTACT
150 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*ATEND)
160 *EXIT BKPBRMEXT BACKUP(*FULLACTIVE) WHEN(*AFTER)

Stuff for you to know:

1) It is BRMS *CONSOLE processing, so the system automatically enters
restricted state.

2) The *EXIT points at seq 10, 20, 150, and 160 is a CL program BKPBRMEXT I
wrote that does housekeeping such as sending messages and/or emails,
stop/start order processing, journal maintenance, hold/release the journal
maintenance job scheduler job, UPS monitoring, etc.

3) The *EXIT point at seq 60 is a CL program BKPRSTNRM I wrote that starts
the controlling subsystem. My startup CL program puts an entry on a data
queue when finished. This *EXIT waits up to 10 minutes on that data queue
entry. If not received within 10 minutes, it moves on (it actually takes
only about 1 minute). After this step, the entire system is back active
except the journal receiver maintenance job scheduler job is not yet
released. (That happens at the very end.)

4) The *EXIT points at seq 100, 120, and 130 are to stop/start the QHTTPSVR
subsystem so that the *LINK at seq 110 will save everything without issue.

5) The omit list in BRMS ("QLNKOMT") omits the following in the *LINK save
at seq 110:
/Bytware/StandGuard/AV/logs
/FAXD01/RCVFAX
/easy400apc/logs
/QIBM/UserData/OS400/MGTC/service


Timings:

From the start of the backup to the message "Subsystem QCTL started"
(meaning restricted state is being lifted) is 14 minutes. It takes a few
minutes for everything else to get going, but restricted state has been
reduced to no more than 20 minutes.

For seq 100 through 130. The time from "Subsystem QHTTPSVR ending in
progress." to "Subsystem QHTTPSVR started." is 20 minutes. The *LINK save
takes a while!

The grand total time for the backup was 87 minutes, of which ~20 minutes
was restricted state. Before, when the entire backup was in restricted
state, the grand total time was 74 minutes.

I will trade the extra 13 or so minutes for the entire process in exchange
for getting down to 20 minutes in restricted state.

This backup will run at 3am when, normally, no one will be on the system
save maybe the night crew manager. So I don't know exactly how well it
would work in the middle of the day when everyone is banging away on the
keyboard.


Many, many, many thanks to a number of people here who offered suggestions
and gave answers to my questions. I ask far more questions here than I
ever answer. I do not know how I would survive in this job without
midrange dot com.






On Wed, Jan 23, 2013 at 4:13 PM, Paul Nelson <nelsonp@xxxxxxxxxxxxx> wrote:

The first is the Apache server.
The second is/was used for CGI stuff.
The third is for iSeries Web Access.



Paul Nelson
Cell 708-670-6978
Office 512-392-2577
nelsonp@xxxxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Crosby
Sent: Wednesday, January 23, 2013 3:10 PM
To: Midrange Systems Technical Discussion
Subject: Re: BRMS - full save with least amount of restricted time

Yea, except there are 3 servers configured to not start. They are:

APACHDFT
CGIDEV2APA
IWADFT

No, I don't know what they are for.






On Wed, Jan 23, 2013 at 3:49 PM, <rob@xxxxxxxxx> wrote:

Doesn't this work?
STRTCPSVR SERVER(*HTTP) HTTPSVR(*ALL)


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 01/23/2013 03:42 PM
Subject: Re: BRMS - full save with least amount of restricted time
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Hey, dumb question here.

In my last test I ended/started subsystem QHTTPSVR. I just did a
WRKACTJOB
and none of the HTTP server instances are running.

I mistakenly assumed that starting that subsystem would start the http
servers configured to autostart. I did some digging and it seems STRTCP
is
what starts those http servers. I'm not ending TCP so therefore I'm not
starting it either.

Evidently I have to do a STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN) as well
as
a STRTCPSVR for each instance I want started? That seems odd. There has
to be a better way such that, with one command, I start the http server
instances configured to autostart..



On Wed, Jan 23, 2013 at 3:18 PM, <rob@xxxxxxxxx> wrote:

Just remember, if you do ever save in a fully restricted state you can
use
OMITS(*IGNORE) on the STRBKUBRM.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx
,
Date: 01/23/2013 03:04 PM
Subject: Re: BRMS - full save with least amount of restricted
time
Sent by: midrange-l-bounces@xxxxxxxxxxxx



I tried another test of saving the IFS today (while active) in BRMS.

Control group:

10 *EXIT ENDSBS SBS(QHTTPSVR) DELAY(60) ENDSBSOPT(*NOJOBLOG)
20 *LINK *ALLAVL FFFFFFF *YES *YES BACKUPS *NONE
30 *EXIT STRSBS SBSD(QHTTPSVR/QHTTPSVR)

These are my *OMITS as defined in QLNKOMT:

/Bytware/StandGuard/AV/logs
/FAXD01/RCVFAX
/QIBM/UserData/HTTPA/admin/logs (probably unneeded as I'm stopping
QHTTPSVR)
/QIBM/UserData/OS400/MGTC/QIWIRELESS/logs
/easy400apc/logs
/QIBM/UserData/OS400/MGTC/service

It worked, so to speak. What I mean is 1 object was not saved
(/QIBM/UserData/OS400/MGTC/config/McEPConfig.properties) as it said the
object was in use. This particular object was not an issue prior to
this
test. However, I was messing around with Management Central during
this
control group execution and I'm thinking I may have caused the issue.
I
kept my hands off Management Central after that.

A test of this control group again tomorrow morning to prove it, then
I'm
ready for a final test Saturday morning of the entire system.




On Wed, Jan 23, 2013 at 9:43 AM, Jeff Crosby
<jlcrosby@xxxxxxxxxxxxxxxx>wrote:

No jury duty today. Trial cancelled. Woo hoo!

On Mon, Jan 21, 2013 at 11:47 AM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:


OSGI, I don't have so I can't see into the directory but if they are
log
files or flight recorders, again not needed for a recovery


Found this IBM document:








http://www-01.ibm.com/support/docview.wss?uid=nas1631d7869f4c9bfa58625773800
5de266



Which tells me how to avoid the object locked messages for directory
/QIBM/UserData/OS/OSGi/LWISysInst, which is the bulk of them. ENDSBS
SBS(QHTTPSVR) and STRSBS SBS(QHTTPSVR)

I can just add a couple of *EXIT statements surrounding the *LINK
save
to
handle that.


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

The opinions expressed are my own and not necessarily the opinion of
my
company. Unless I say so.




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

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.


--
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

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.


--
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

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.



--
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 thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.