A couple more questions here, then I hope I'm good to go.

1) The STRBKUBRM will be run with SBMJOB(*CONSOLE). Normally, BRMS would
restart the controlling subsystem at the end. BRMS won't fall over at the
end because I've done it in the middle, will it? For all I know, the BRMS
console may already be checking to see if the controlling subsystem is up
before trying to start it.

2) My QSTRUP program only takes 40-45 seconds. However, QSYSOPR shows
various things happening after that. For example, the message "STRTCP
completed successfully" doesn't show up for another 5 minutes. Are you
truly moving on in the control group after QSTRUP is done (ie, 40-45

3) If I use a data queue to determine that QSTRUP has ended, it seems to me
that I want to clear this data queue in my BRMS *EXIT program, not in
QSTRUP itself.

I will probably be testing this stuff a week from Saturday and just want to
keep the Saturday time as brief as possible.

Thanks again for your help. These forums are a godsend.

On Thu, Jan 10, 2013 at 3:18 PM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:

Yes you could just start the controlling subsystem but I would make sure
you put in some control points and error handling. That's when a data
queue comes in really handy. Have the start up program put an entry
into the queue. The CL in the control group waits for the data queue
entry and off you run. Now you don't have to guess how long it takes to
run the start up program.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On 1/10/2013 2:11 PM, Jeff Crosby wrote:
Doh! (slapping forehead) You're doing it with a single control group.
was thinking 2 separate control groups with the first restricted.

All I have to do in that CL is start the controlling subsystem, right?
you put a delay in that CL to give it some time after the STRSBS is run?
I've still got my "restore system to normal state" program from years
when I didn't have BRMS and that's what I did.

On Thu, Jan 10, 2013 at 3:03 PM, Jim Oberholtzer<
midrangel@xxxxxxxxxxxxxxxxx> wrote:

The control group calls the CLP program via *EXITs. Now just start
console monitor, submit the BRMS job to *CONSOLE and stand back.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

On 1/10/2013 1:57 PM, Jeff Crosby wrote:
> Thanks, Jim.
> How do you do that with a CL program, when restricted state gets
> What I mean is this. We have the Advanced Job Scheduler, which
is used
> do the restricted state backups. The AJS job command is:
> Are you saying you replaced that with CALL MYCLPGM and it did it
all? As
> in that CL program has 2 STRBKUBRM commands in it? That can't
be, I
> think, because restricted state will kill your CL program. And
> smarter than that so I'm obviously not understanding something.:)
> On Thu, Jan 10, 2013 at 2:26 PM, Jim Oberholtzer<
> midrangel@xxxxxxxxxxxxxxxxx> wrote:
>> > Jeff,
>> >
>> > The main concern with save while active on an *ALLUSR is
when you use
>> > any synch point except *LIB. *SYNCLIB and *SYSDFN may
take a LONG
>> > to reach a synchronization point with all of the
libraries on the
>> >
>> > If you use *LIB as the save while active synchronization
point you
>> > should not have any issues, I do it all the time.
>> >
>> > I also use the technique you mention with two control
groups, one for
>> > restricted state for what ever is needed there, then
bring the system
>> > back up for use and start a save while active on the
other libraries.
>> >
>> > I use a control language program to do it so I can
manage the shut
>> > and start up properly.
>> >
>> > Jim Oberholtzer
>> > Chief Technical Architect
>> > Agile Technology Architects
>> >
>> >
>> > On 1/10/2013 1:13 PM, Jeff Crosby wrote:
>> > <snip>
>>> > > I read in "Backup Recovery and Media Services
>>> > > for OS/400: A Practical Approach" (PDF available
>>> > >
http://www.redbooks.ibm.com/abstracts/sg244840.html) that save
>> > active
>>> > > is strongly discouraged with *ALLUSR. The last
update to this
>> > was
>>> > > 2003, so I'm wondering if that's changed. Anyone
doing *ALLUSR
>> > 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,
>> > 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.
>> > </snip>
>> > --
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 thread ...


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