Michael,
Hope all is well. Send me an email the next time you come to town.
You could try this:
1) Change *QSTRUPPGM to *NONE
2) Restrict system
3) Hold certain job queues that process user jobs just in case the scheduler releases one before you can restrict again (QBATCH, etc..)
4) Run the full system save "go save 21"
5) As soon as the save is done....issue command to restrict the system
6) Change IPLA to start in restricted state
7) Perform checkouts and pre-upgrade tasks.....then do IPL to image catalog for the OS upgrade
8) System will come up in restricted state, finish upgrade
9) Check out system, change startup system value
10) Load cumulative and other PTF packages then IPL
11) Issue command to start controlling subsystem
Not sure if you have BRMS, but if it were my systems I would do the following:
1) Change IPLA to start in a restricted state
2) Create a BRMS control group to do a FSS then IPL automatically
3) Submit job to run your BRMS control group to the batch controlling SBS (automated FSS)
4) Get coffee and breakfast because this approach is automated and there is no chance the scheduler will activate after the IPL to a restricted state
5) Verify backup, issue change IPLA to start in restricted state again (prior to OS upgrade IPL)
6) Check out system, change library list system value & alwobjrst system value, check DB cross reference, verify "go licpgm #5" again, load OS catalog to virtual optical
7) IPL from the OS image catalog source
8) Finish upgrade, perform checkouts while in restricted state
9) Return changed system values
10) Load your PTF catalog to virtual optical, load fixes, IPL to apply
11) System will come up normally....verify PTFs, checkout system.....done!
***********************************
Bradford Lovelady
Operating Systems Engineer
Technology Infrastructure Services
Wells Fargo Bank l 200 Wildwood Pkwy l Birmingham, AL 35209
MAC W2691-010
Tel 205-938-1999 l Cell 205-826-2834
brad.lovelady@xxxxxxxxxxxxxx
Wells Fargo Confidential
This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Smith
Sent: Friday, March 15, 2013 7:18 AM
To: Midrange Systems Technical Discussion
Subject: RE: IBM job scheduler
Agree.
"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."
Work around (2):
1> Enhance QSTRUP to read dataarea, before starting QCTL.
2> Set a dataarea ; "Do not run"
3> HLDALLJOBQ *ALL/*ALL
4> Execute the Go Save>Opt 21 function (the system is reduced to a restricted state)
5> QCTL will start, but all JOBQ's are on hold, no batch/interactive
5> jobs will start
6> QSTRUP will read the dataarea; ENDSBS *ALL and return based on "Do not run"
7> Perform business tasks
8> Set a dataarea ; "Run"
9> Manage *JOBQ's and associated jobs
10> Call QSTRUP
--
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.
As an Amazon Associate we earn from qualifying purchases.