Re: IBM job scheduler

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.