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
Michael
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, March 14, 2013 2:30 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: IBM job scheduler
On 14 Mar 2013 08:40, Michael Smith wrote:
Is there a way to "hold" the IBM job scheduler (NOT the Advanced Job
Scheduler)?
So that would be the system job QJOBSCD I presume.
I know that you can "hold" an individual entry, I am interested in
preventing the job scheduler from starting after executing a "system
backup".
Does the "after" imply what transpires /after/ starting the controlling subsystem?
Maybe explaining the reasoning behind wanting to do so, perhaps a specific example, would expose alternatives. If for example there is a desire to review what is on the scheduler, then why not review and choose what specific work to hold before starting the "system backup"
activity? Or maybe review and choose what work to hold before starting the controlling subsystem after the backup? I can make little sense of why there is a need\want to do so... if my questions do not make that obvious :-)
Because the QJOBSCD is a system job, that job never actually ends even during any /restricted state/ activity, such as a "system backup".
A system job could even submit jobs while in restricted state, because no subsystems would be taking entries off of job queues because none are active. If the jobs are submitted to the job queue, then reviewing the WRKJOBSCDE information /after/ the backup may not be able to accomplish what is desired. However that system job could /sleep/ upon entering restricted state with either polling on exiting the restricted-state condition or perhaps instead wake-up on an out-of-restricted-state event.
So anyhow...
That means holding all job queues into which jobs were\are started from that feature would prevent any work from starting, regardless of the work having been either added to the job queue during restricted state or added soon\immediately after starting the [controlling sub]system. But of course, doing that would hold\prevent any other work entering subsystems via those Job Queues as well. Yet maybe the real intent is to stop all unattended\submitted work for review.?
But for lack of a HLDSYSJOB command [like there is CHGSYSJOB], one
*could* use the knowledge of how that job operates in and [just] after restricted-state, to activate debug and a breakpoint to prevent the job from doing work. Because the job is apparently responding to events, work stopped at a breakpoint would likely just stack new work entries at the same breakpoint on a new [recursion] stack level. Without a BKPPGM, which perhaps would be defined as a delay until a specific time by which the /hold/ should be released and also to RMVBKP when that time has passed, having to deal with many stacked breakpoints interactively can be frustrating because that requires a display at which Enter can be pressed to get past all the prior breakpoints hit before removing the breakpoint because debug can not end while at a breakpoint. And I am loathe to signoff while servicing a system job versus an orderly unstacking of everything by ending debug, and then ending servicing, because if the service\debug get /confused/ I may be unable to re-initiate servicing.
--
Regards, Chuck
--
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,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
