Re: IBM job scheduler

We have the Advanced Job Scheduler where this would be (I think) really
easy to do. Just stop the monitor job. I say I _think_ it would be easy
because I've never actually done it.

In any case, wouldn't the regular job scheduler also have some monitor
that's running? I mean _something_ has to fire off those jobs.



On Thu, Mar 14, 2013 at 3:24 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 14 Mar 2013 11:30, CRPence wrote:

<<SNIP>>

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. <<SNIP>>

Hmmm... There should be the fully-supported option of using Save of
the *JOBSCD object, RMVJOBSCDE for *ALL entries [or HLDJOBSCDE for *ALL
entries], then Restore of the *JOBSCD object afterwards. But as noted
in my prior message, the scheduled work may get put on the job queues
even during restricted state, so the timing of the object-save and the
removal [or the holding] of *ALL entries might need to be done before
versus after the "system backup" activity... thus the "system backup"
would not be saving the Job Scheduler object for its expected entries
:-( The save\backup strategy would need to account for that effect.
This method would avoid having to use the API to parse and decide what
to hold, to record what was held, and then to release what was tracked
as previously being held.

FWiW... and probably not of general interest:

If the QJOBSCD can be confirmed to obtain a lock on the QDFTJOBSCD
before moving any work to a job queue [seems improbable], then I suppose
there is the possibility of using a system-domain program to use the MI
LOCK to allocate that *JOBSCD object with an exclusive lock.... and hope
that the system job is coded to respond /nicely/ to what would
presumably be a somewhat unexpected condition; i.e. long-held versus
likely always available within [albeit shorter than non-system jobs] the
job Default Wait (DFTWAIT) time for the system job.

Like noted first in this reply, there could be the possibility of
save, delete, then restore the object. But like locks, how the system
job responds to the missing [versus locked] object is important. I
believe it just creates a replacement when found to be missing. A
rename could work in place of delete, if the object is not addressed by
a stored pointer. However I am not sure what the options there would be
for delete [no DLTJOBSCD] or rename [no OBJTYPE(*JOBSCD) on RNMOBJ];
i.e. if any APIs support that object type for those requests. But again
when the work may get put on the job must be considered, and again
whether the 'system backup' might end up saving the empty or all-held
Job Scheduler object entries.

Of course if someone could articulate a requirement to be able to
HLDJOBSCD [the imaginary command; i.e. not HLDJOBSCDE] or even HLDSYSJOB
if the possibility of a need for more jobs that might allow that feature
to act upon their jobs, that would be a better approach than monkeying
around with debug, locks, etc. things that would depend on the
implementation details of the JOBSCD\SCDE feature. IMO being able to do
something like this for post-crash might be arguably worthwhile, but I
would not expect a request for that capability being argued for
post-backup to get any traction. For post-backup I think the response
from IBM would be like that others have suggested, to use the API to
hold whatever should be held, and release those that were previously
held for those reasons whenever that is\becomes desirable. Or perhaps
the suggestion I opened with, in this message.

--
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.