Re: BRMS - does *CONSOLE automatically result in a restricted system save

[Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>]

Jeff,

Sign off Interactive users does just that.  It does not necessarily 
result in a restricted state.  You can get all of the subsystems to stop 
by using the "Subsystems to process" Option 9 from the control groups 
menu (WRKCTLGBRM) but that will simply stop and optionally start the 
subsystems you put in there.  If you put *ALL in there it claims to take 
it to a restricted state and is intended for restricted state operations 
such as *SAVSYS save.   If you do that remember to set the restart so 
the control group will restart the controlling subsystem when it ends.   
I have not tried that specifically (all my comments are based on V7)

SBMJOB(*CONSOLE)  will allow the system into a restricted state as long 
as the console monitor job has been started (Option 20 from the BRMS 
menu).  More importantly it will do it unattended while you sleep.  You 
can also get a restricted state by submitting the back up job to the 
controlling subsystem but I am  not a big fan of that since you will not 
have any access to the console until the job finishes and restarts 
everything.

You best option is SBMJOB(*CONSOLE) after starting the console job.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 1/17/2013 9:45 AM, Jeff Crosby wrote:
> What causes restricted state in BRMS?  Is it SBMJOB(*CONSOLE)?  Or is it if
> the BRMS control group says "Sign off interactive users . . . . . . . *YES?"
>
> For example, this statement in a job scheduler:
>
> STRBKUBRM CTLGRP(BLAHBLAH) SBMJOB(*CONSOLE)
>
> If BRMS control group BLAHBLAH says "Sign off interactive users . . . . . .
> . *NO" will restricted state be entered or not?
>
>
> -- 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.
> --