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.