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
You best option is SBMJOB(*CONSOLE) after starting the console job.
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.