Re: Using the command DLYJOB in a CL program

[CRPence <CRPbottle@xxxxxxxxx>]

  Or a message queue.  Both queue types support a WAIT timeout which in 
some cases can almost directly replace a DLYJOB request, although with a 
monitor for the timeout added; plus ensuring a destructive read [e.g. 
RMV(*YES) on RCVMSG] which removes the "message" from whichever type of 
queue [*DTAQ or *MSGQ] being used.

  However if the application can neither create nor clear the queue at 
startup and before any successive delay requests, then coding to the 
queuing timeout versus DLYJOB can become more complex in design [than 
may be desirable for a particular, perhaps utility, application].  For 
example a SNDPGMMSG to the message queue named by RCVMSG can easily 
implement a CONTINUE command for the application, but the message being 
sent just a microsecond after the "current" RCVMSG has already 
completed\timed-out could cause the "next" RCVMSG to experience no wait 
:-( since a\the message is already there to be received.  So care must 
be taken to synchronize the application and the requester(s) of any 
continuance of that application over multiple coded delays.

Regards, Chuck

On 04-Jan-2012 19:06 , Mike Cunningham wrote:
> Not sure what the real need is on this but one way to allow you to
> control when a batch job "wakes up" is to use a data queue. Have the
> CL loop looking for a data queue entry and go to sleep again if there
> isn't one. When you want the job to run send something to the data
> queue
>
> Scott Klement  on Wednesday, January 04, 2012 5:08 PM
>
> <<SNIP>>
>
> So... there are all sorts of ways to work around the issue... but if
> your goal is purely to change the IBM-supplied DLYJOB command while
> it's running, then I'm afraid you're out of luck.