"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.
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"
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, March 14, 2013 6:47 PM
Subject: Re: IBM job scheduler
On 14 Mar 2013 13:11, Michael Smith wrote:
The specific requirement is
1> "hold" the job scheduler before an Go Save>Opt 21 is executed so
that "jobs" including the job scheduler jobs will not be allowed to
run after the Opt 21 is completed
2> We will then be able to perform business tasks, including but not
limited to OS upgrades, RCLSTG.
3> Execute the QSTRUP program, "release" the job scheduler
While there is no explicit "hold" nor explicit "release" for the QJOBSCD job, isn't that already effectively what transpires? 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.
Whether or not the jobs would get to the Job Queues while the system is in restricted-state is moot because no jobs can start while the system is in restricted state. But the help text for the ADDJOBSCDE [and\or perhaps other CMDSCDE command help] seems to suggest that the jobs are not placed on the *JOBQ during restricted-state; and the recovery action for the scheduled job entry defines how to handle the missed opportunity for the scheduler to have started the jobs due to the system being effectively unavailable. The STRSBS of the subsystem named in the system value QCTLSBSD determines when the QSTRUPPGM would be invoked, and starting that Controlling Subsystem [from status END ¿or is that ENDING?] is what takes the system out of restricted-state.
So it seems that a conspicuous resolution is to ensure for the described requirements, that the end of the backup activity does not restart the controlling subsystem. That is, the STRSBS should be deferred *until* the time that job scheduling activity is henceforth desirable; i.e. the system remains in restricted-state. That would mean that no scheduled job activity will transpire since the ENDSYS [or ENDSBS *ALL] went into effect. Again, what those jobs scheduled to start during that time spent in restricted-state [or pwrdwnsys\IPL] sequences would be handled according to the Recovery Action (RCYACN) parameter of the ADD or CHGJOBSCDE]. For any PwrDwn\IPL sequence however, to ensure the job scheduler continues to postpone starting any jobs, the *IPLA option for the Power Down with Restart must be chosen, and the CHGIPLA should establish that the system restart into restricted-state... because ENDSYS after the system finishes the IPL would be too late.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l