On 14 Mar 2013 16:11, Michael Smith wrote:
"The only issue I believe, would be that the GO SAVE option-21
either should be modified to [or asked to; perhaps via
changed\stored defaults?] *not* restart the controlling
subsystem after it completes"
This would be the best solution, but it isn't available at the
present time.
Work around:
1> Enhance QSTRUP to read dataarea, before starting QCTL.
2> Set a dataarea ; "Do not run"
3> Execute the Go Save>Opt 21 function
(the system is reduced to a restricted state)
4> QSTRUP will read the dataarea and do a return
based on "Do not run"
5> Perform business tasks
6> Set a dataarea ; "Run"
7> Call QSTRUP
I am confused about the proposed approach. I do not think that will
assist to achieve what has been stated as desired; i.e. prevention of
the job scheduler from starting scheduled work.
The GO SAVE option-21 will not CALL QSTRUP.?.? AFaIK the end of the
backup activity which was conducted since ENDSYS placed the system in
restricted-state, will issue the request to effectively:
STRSBS SBSD(*CTLSBSD) /* where the theoretical *CTLSBSD is the name
resolved from the system value QCTLSBSD; I have always wondered why
there is no such special value for that parameter */
The QSTUPPGM is invoked as a *consequence* of starting the QCTLSBSD
[which presumably is QCTL in this scenario]. And the STRSBS QCTL will
change the status of the QCTL SBS monitor job from END to DEQW, which
will also [effeectively] simultaneously have the "restricted-state"
indicator turned off... probably long before the QSTRUPPGM gets called;
not that when is really relevant at that point. Thus the STRSBS QCTL
also causes, as a side effect, the QJOBSCD system job to stop awaiting
the system coming out of restricted-state. That is because either the
system job QJOBSCD was since informed by an event that the system is no
longer in the restricted-state, or that the polling by QJOBSCD for the
status has since detected that same /no-longer-restricted-state/ condition.
So while the described approach can stop user-activated [generally
post-IPL] work and the invocations of the remainder of the /system/
startup [like starting various subsystems for spooling, comm, et al],
there seems to be no hope that having done so will also prevent the
QJOBSCD from activating the scheduled jobs.
