×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 04-Jan-2012 13:37 , Alan Shore wrote:
<<SNIP>> My question is only pertinent to the DLYJOB command itself -
whether or not the program is being debugged.
1. Is there any way of knowing the amount of elapsed time, and
therefore the amount of time left?
Calculated, as others have mentioned, since the timestamp of the
request message that was logged. Should be possible to write a utility
to do the calculation using the List Job Log Messages (QMHLJOBL) API to
retrieve that last message from the joblog, but I doubt there is a LIFO
option or similar means to get to the last request message quickly and
conveniently.
2. Is there a way of changing this timespan while the program is
running?
AFaIK effectively only by changing the timing of the [passing of the]
event being signaled; i.e. as a time-of-day [TOD] event having been
established as a clock-timestamp of either invoked_TOD+DLY(seconds) or
RSMTIME(TOD). Thus for example, changing the system value QTIME
[¿and\or QDATE?] to a value beyond the time which would have that event
signaled. I do not believe the DLYJOB is implemented using any timers
for which there is an external capability to review or reset the timer
itself.
While many events will supersede the TOD event which was established
by and awaited in the job performing DLYJOB, only things like EndRqs,
EndJob, and RclActGrp would actually stop the wait on the TOD event
being signaled. If for example the job had a break message handler
event active which responded with ENDRQS upon receipt of a message, then
the DLYJOB would be interrupted; but so too would the active program [as
controlled by the defined\registered invocation exit]. If the DLYJOB
were implemented in its own stack entry, the processing would probably
be easiest; the call to the program doing the DLYJOB could signal an
exception that is monitored by the caller.
There is the sleep() [or usleep()] "Suspend Processing for Interval
of Time" API which can be signaled to end in an alternate manner by
defining a signal action for a process signal monitor to "Handle the
signal by running signal-catching function" versus the signal monitor
default actions.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/unix5a2.htm
The documentation for sleep() suggests that "If an unblocked signal
is received during this time and its action is to call a signal-catching
function, to end the request, or to end the process, sleep() returns
immediately with the amount of sleep time remaining."
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/sigsleep.htm
The documentation for the getitimer() Get Interval Timer and
setitimer() Set Interval Timer both document a signal handler "catcher"
for the SIGALRM.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/setitime.htm
Note: Some of the documented service program name in various doc
links [some of those included above] appear to have named QPOSSRV1
instead of QP0SSRV1 :-(
Regards, Chuck
midrange.com
