I have a job always abend in this step with S322 error. No matter what number was set to TIME parameter in the job card it still abend with S322.
On the other hand I also find that there is a temporary table will be generated in QMF proc:PROD.P_USQSP1MO and erased when the proc finish. Every time the abend happened during a query tried to select this temporary table. I tried to do a RUNSTATS on this temporary table and then reran this step. This time it ran successfully.Can anybody tell me the reason and how to avoid this kind of problem happen again,thanks!
Edited: Please use BBcode when You post some code, that's rather readable, Thanks...Anuj
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
Are you sure that your JOB statement TIME parameter wasn't overridden by your site standards? What job class did it run in? How much time is allowed at your site for that particular job class?
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
How many rows are put into the temporary table for this process? Does the run that succeeds process less data than the one that fails?
Did some process run that deleted some/many of the rows in the table used by this process to create the temporary between the abended run and the successful run?
Typically, a query that processes a similar number of rows will use a similar amount of cpu time. If the run sometimes succeeds and sometimes abends with a 322 (and is running in the same CLASS), the volume of data may be the difference.
How many total rows are processed in any table (temporary or real) in the run that abends?
Are you sure that your JOB statement TIME parameter wasn't overridden by your site standards? What job class did it run in? How much time is allowed at your site for that particular job class?
Thanks Terry,
Actually the original parameter is TIME=10 and this job has been there running for many years.It just suffered this problem recent few months.It's weird that every time I must do a RUNSTATS on that temporary table after it abend with S322 and then this step can run successfully.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
It's weird that every time I must do a RUNSTATS on that temporary table after it abend with S322 and then this step can run successfully.
This should be unacceptable. . .
The process needs to be corrected so that it will run successfully the first time. Proper analysis should show whether something could be done with the query(ies), the index(es) available for the process in either the input or output, or possibly simply running with a greater TIME parameter.
If the data has grown over time, it is reasonable to use more time than previously. When the job runs successfully, how much cpu time does it require?
It's weird that every time I must do a RUNSTATS on that temporary table after it abend with S322 and then this step can run successfully.
This should be unacceptable. . .
The process needs to be corrected so that it will run successfully the first time. Proper analysis should show whether something could be done with the query(ies), the index(ex) available for the process in either the input or output, or possibly simply running with a greater TIME parameter.
If the data has grown over time, it is reasonable to use more time than previously. When the job runs successfully, how much cpu time does it require?
Hi Dick,
After I do RUNSTATS on it , the step will only take no more than 1 minute to finish.
