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

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