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

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. I
was thinking 2 separate control groups with the first restricted.

All I have to do in that CL is start the controlling subsystem, right? Do
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 ago
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 the
> 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

> involved?

> >
> > What I mean is this. We have the Advanced Job Scheduler, which is used

> to

> > do the restricted state backups. The AJS job command is:
> >
> > STRBKUBRM CTLGRP(FULLWTHSYS) SBMJOB(*CONSOLE)
> >
> > 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

> don't

> > think, because restricted state will kill your CL program. And you're

> much

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

> time

> >> > to reach a synchronization point with all of the libraries on the

> system.

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

> down

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

> >> > </snip>
> >> > --

> --