Re: Delay job from RPGLE

On 09 Jul 2013 11:13, Buck Calabro wrote:

On 7/9/2013 1:51 PM, Jon Paris wrote:

I can't see any real value to using DLYJOB when you can use
sleep(). In order to DLYJOB you have to go through two additional
layers of code (QCMDEXC and DLYJOB) to get to the same place - that
takes horsepower.

I have also seen customer situations where this overhead caused
poll intervals to be missed - admittedly when doing 1 second or
less intervals but ...

Along those lines, this thread lays out several alternatives:
http://archive.midrange.com/rpg400-l/200302/msg00527.html

As discussed in that referenced thread, the DLYJOB could be in a CLLE procedure to more seamlessly integrate the function of the CL request.

IIRC a lamentation occasionally expressed in the past, was loss of the CMD-DLYJOB appearing in the WRKACTJOB when using other features like usleep() to effect a delay. Apparently that additional visual "Function" was considered revealing as to the origin for the TIMW overall job status.? The reasoning may have been to distinguish an obviously explicitly coded wait request in the application from other waits that might originate from some OS function called by the application; e.g. a request of the OS, doing something unlikely to utilize a DLYJOB. So FWiW, since v6r1, the capability exists to set that "Function" to a 10-byte value designated as a user-specified function-type using the following API:
http://pic.dhe.ibm.com/infocenter/iseries/v6r1m0/topic/apis/qwcccjob.htm
_i Change Current Job (QWCCCJOB) API i_
"...
Function name. Additional information about the last high-level function initiated by the initial thread. When the Function name is set with this API, the Function type field is automatically set to a value indicating User-specified.
..."