× 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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.