Re: MI program unable to locate job - need assistance

"Paul Jackson" <[email protected]> Tue, 20 May 2008 18:48:43 -0700
Newsgroups gmane.comp.lang.as400.mi
Message-ID <[email protected]>
On Tue, May 20, 2008 at 4:53 PM, Simon Coulter <shc-Q/[email protected]> wrote:
>
> On 21/05/2008, at 8:05 AM, Paul Jackson wrote:
>
>> Which seems normal
>
> Yes. The pointer is NULL prior to being set then is set to the first
> WCBT.
>
>> but the based on WCBTBL-SPACE var is all hex zero
>> which means that the size is set to zero (it should be 16752384) which
>> causes the tables to be skipped hence the not found option.   On the
>> other systems the size is correctly populated and so the table is
>> searched normally.
>
> I've not seen that before. I guess it could mean that QWCBT01 is not
> used (damaged/skipped/empty).
>
> What does DSPJOBTBL show on the failing system?
>
> What does DMPSYSOBJ QWCBT01 QSYS show on the failing system (only
> need the first page)
>
> When was the last time the job tables were compressed on the failing
> system? Perhaps arrange to have the tables compressed: CHGIPLA
> CPRJOBTBL(*ALL) CHKJOBTBL(*ALL) then IPL. Reset these values after
> the IPL. Then see if the program works.
>
> NOTE: Good idea to ensure QTOTJOB, QACTJOB, QADLACTJ, QADLTOTJ, and
> QMAXJOB are set appropriately before the IPL.
>
> NOTE: Collect the DSPJOBTBL and DMPSYSOBJ information first then
> compress the tables.
>
> While it is interesting to pursue this particular problem I suggest
> that altering your approach would be better. Either:
>        a) Modify the MI program to use the job index to locate the given job
> or
>        b) Use Mark's suggestion of the Interrupt Job API
>
> The advantage of a) is that it will be much faster. The advantage of
> b) is that it will work without requiring system-state.

Hey Simon,

By dumping the tables I found out that the table size on the failing
system is stored at position 4117 instead of 21.  So by adding a
conditional test on whichever one was not zero I was able to fudge the
program.  I also changed the start offset to the entries to x'1300'
(based on the job table dumps).

I found (by dumping the job tables) that another two of our systems
exhibit this behavior.

All Lic and OS versions exactly the same.

I agree that an alternate method would be better, but for now this
works.  Thanks for your help!

Paul Jackson
_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.