macheadpdx wrote:
> Hi,
>
> We have a web application that access data from the iSeries using
> stored procedures and functions through JDBC. Every once in a while a
> job will just go out of whack and fall into a "Waiting for thread"
> status (THDW). At this point this job takes all available CPU and it
> takes a long time to end it. In most instances we need to re-IPL the
> machine to kill the job.
>
> Any ideas why this could be happening? I check all our stored
> procedures and functions and eveything seem to work fine.
>
> Any help/ideas will be greatly appreciated. I'm running out of clues
> and this seem to get even worse as days go by.
>
> OS Ver: V5R3M0 040528 (all PTFs current)
> JT400 Open driver: v4.9
>
> Thank you very much in advance!
>
> Erick
>

There is a V5R4 PTF (SI21187) with a similar description. However I
don't see a V5R3 PTF. More info here (search using the PTF no.):
http://www-912.ibm.com/a_dir/as4ptf.nsf/as4ptfhome

In any event you may want to work with your IBM service provider to
investigate further.

--
Karl Hanson

Java UDFs by any chance? FWiW: APAR= SE22982 has a correction in
v5r4 only, for a thread wait condition when using a Java UDF. But there
is no mention of any CPU issues; i.e. it appears only to address a WAIT
condition.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind whatsoever.

macheadpdx wrote:
> Hi,
>
> We have a web application that access data from the iSeries using
> stored procedures and functions through JDBC. Every once in a while a
> job will just go out of whack and fall into a "Waiting for thread"
> status (THDW). At this point this job takes all available CPU and it
> takes a long time to end it. In most instances we need to re-IPL the
> machine to kill the job.
>
> Any ideas why this could be happening? I check all our stored
> procedures and functions and everything seem to work fine.
>
> Any help/ideas will be greatly appreciated. I'm running out of clues
> and this seem to get even worse as days go by.
>
> OS Ver: V5R3M0 040528 (all PTFs current)
> JT400 Open driver: v4.9
>
> Thank you very much in advance!
>
> Erick

Thanks to your replies!

We never saw this problem when we were in V4 Release xx. It just
started happening randomly when we migrated to a new box new OS
version.

> We have a web application that access data from the iSeries using
> stored procedures and functions through JDBC. Every once in a while a
> job will just go out of whack and fall into a "Waiting for thread"
> status (THDW). At this point this job takes all available CPU and it
> takes a long time to end it. In most instances we need to re-IPL the
> machine to kill the job.
>
You re-IPL the AS400 to deal with a problem job?! If ENDJOB *IMMED
doesn't do the trick, there is also ENDJOBABN (though if you tried
ENDJOB first, you have to wait 10 minutes before you can use
ENDJOBABN). If there is a problem because the runaway job is concuming
all CPU, have you tried Holding it before issuing the ENDJOB command?

On May 15, 2:37 am, "walker.l2" wrote:
> > We have a web application that access data from the iSeries using
> > stored procedures and functions through JDBC. Every once in a while a
> > job will just go out of whack and fall into a "Waiting for thread"
> > status (THDW). At this point this job takes all available CPU and it
> > takes a long time to end it. In most instances we need to re-IPL the
> > machine to kill the job.
>
> You re-IPL the AS400 to deal with a problem job?! If ENDJOB *IMMED
> doesn't do the trick, there is also ENDJOBABN (though if you tried
> ENDJOB first, you have to wait 10 minutes before you can use
> ENDJOBABN). If there is a problem because the runaway job is concuming
> all CPU, have you tried Holding it before issuing the ENDJOB command?

Hello,

We tried everything to try and end this job. We tried to hold it
before ending the job but it won't go on hold. We also tried to
lower the priority of the job to 99. In some cases this works, but
mostly not.

On May 17, 1:25 pm, macheadpdx wrote:
> On May 15, 2:37 am, "walker.l2" wrote:
>
> > > We have a web application that access data from the iSeries using
> > > stored procedures and functions through JDBC. Every once in a while a
> > > job will just go out of whack and fall into a "Waiting for thread"
> > > status (THDW). At this point this job takes all available CPU and it
> > > takes a long time to end it. In most instances we need to re-IPL the
> > > machine to kill the job.
>
> > You re-IPL the AS400 to deal with a problem job?! If ENDJOB *IMMED
> > doesn't do the trick, there is also ENDJOBABN (though if you tried
> > ENDJOB first, you have to wait 10 minutes before you can use
> > ENDJOBABN). If there is a problem because the runaway job is concuming
> > all CPU, have you tried Holding it before issuing the ENDJOB command?
>
> Hello,
>
> We tried everything to try and end this job. We tried to hold it
> before ending the job but it won't go on hold. We also tried to
> lower the priority of the job to 99. In some cases this works, but
> mostly not.

Hello, IBM has an excellent tool for analyzing job waits, the tool is
iDoctor for iSeries Job Watcher, you can download a 45 day trial
version from https://www-912.ibm.com/i_dir/idoctor.nsf/JW.html.
There is also online documentation that can help you with getting
started with using the tool and an forum where you can post questions.
Best Regards, Tom

On 18 May, 22:32, JavaEdge wrote:
> On May 17, 1:25 pm, macheadpdx wrote:
>
>
>
>
>
> > On May 15, 2:37 am, "walker.l2" wrote:
>
> > > > We have a web application that access data from theiSeriesusing
> > > > stored procedures and functions through JDBC. Every once in a while a
> > > > job will just go out of whack and fall into a "Waiting for thread"
> > > > status (THDW). At this point this job takes all available CPU and it
> > > > takes a long time to end it. In most instances we need to re-IPL the
> > > > machine to kill the job.
>
> > > You re-IPL the AS400 to deal with a problem job?! If ENDJOB *IMMED
> > > doesn't do the trick, there is also ENDJOBABN (though if you tried
> > > ENDJOB first, you have to wait 10 minutes before you can use
> > > ENDJOBABN). If there is a problem because the runaway job is concuming
> > > all CPU, have you tried Holding it before issuing the ENDJOB command?
>
> > Hello,
>
> > We tried everything to try and end this job. We tried to hold it
> > before ending the job but it won't go on hold. We also tried to
> > lower the priority of the job to 99. In some cases this works, but
> > mostly not.
>
> Hello, IBM has an excellent tool for analyzing job waits, the tool isiDoctorforiSeriesJob Watcher, you can download a 45 day trial
> version fromhttps://www-912.ibm.com/i_dir/idoctor.nsf/JW.html.
> There is also online documentation that can help you with getting
> started with using the tool and an forum where you can post questions.
> Best Regards, Tom- Hide quoted text -
>
> - Show quoted text -

I would certainly concur with Tom, the iDoctor Toolset can help
identify the wait condition with great accuracy, this should then help
you home in on the problem in an attempt to come up with the correct
solution. As stated it has a 45 day trial period which is well worth
doing. Hopefully wiithin the trial period you will identify the issue.
The only problem is that once you've used it, you will not look back
and end up purchasing it :-)

If you do download iDoctor and start using it for this issue and
require further assistance it may well be worthwhile posting back to
this group and/or subscribing to the iDoctorGroup at
http://groups.google.co.uk/group/idoctorgroup - This way hopefully you
should find assistance in using the toolset and with interpreting the
results.

Regards, TheiSpecialist.com