Re: Is there any reason why we don’t see the Call Stack of the Job, when the job is ACTIVE?

On 11/12/10 2:10 PM, Pete Hall wrote:

On 2010-11-12 04:55, rajeev chandel wrote:

Any idea about [Subject:].

Is there any reason why we don’t see the Call Stack of the Job,
when the job is ACTIVE?

I've seen that when the job is using a lot of cpu cycles, like when
running a SQL query that builds an index. It waits long enough to
time out, then shows an empty call stack display.

FWiW the CPU utilization is unlikely to have prevented directly, the display of the *PGMSTK in the index-build scenario. In that scenario, the process [primary thread, or any secondary thread for thread stack] performing the index-build [job status IDX] is operating in the LIC ["below the MI"]. A LIC function can not be interrupted [except by a LIC request], so typically each MI instruction is designed to effect only "quick" operations. The index-build request is at least one exception, a long-running LIC\MI operation [Load\Dump AKA Restore\Save are other examples]. These atypical instructions are interrupt-capable only by either the completion of the task(s) implementing the feature, or an explicit action by the LIC to "look for" an interrupt [often described by the idiom "coming up for air"]. Any unmasked operation, i.e. any non-LIC program processing being performed ["above the MI boundary"], can be interrupted by the MI instruction to materialize the program stack. The WRKJOB or DSPJOB being used to materialize the program stack has a timeout limit [perhaps established by the DFTWAIT for the job] for the materialize request, so when the operation being performed can not be interrupted [such as with the database index build], an error will be logged and the "display call stack" will be empty.

Regards, Chuck