Re: IBM job scheduler

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.