We installed a trial of a hardware web accelerator at a customer some
years back. Over the course of a few hours it had consumed every single
port number between itself and the model 270 the web servers were
running on! At that point it began to fail to deliver content. Turns
out the thing never closed anything, which was part of it's
acceleration. The iSeries just chugged along although temp storage was
through the roof! Said accelerator was summarily returned and we never
saw any performance difference anyway.
- Larry "DrFranken" Bolhuis
On 7/5/2013 11:45 AM, Denis Robitaille wrote:
Thanks everybody for your idea.
We found the culprit and it was not what I expected. The problem was not one job but several thousand ODBC connection that were open by a web service but not closed correctly. So we were stuck with several thousand ODBC job that were juste hanging out there and consuming a little space for each.
Our dev people are now on it to fix this.
Again thanks everybody for the fast comming advices.
Chef de service TI
Cascades Centre des technologies,
une division de Cascades Canada ULC
412 Marie Victorin
Kingsey falls(Québec) Canada J0A 1B0
T : 819 363 6130
Pour toute information sur les événements techniques, veuillez consulter notre calendrier Groupwise CAS_CALENDRIER_TI
<rob@xxxxxxxxx> 2013-07-05 10:41 >>>
Job or CPU Sync Async
Task User Number Thread Pty Util I/O I/O
SS6168R HOLLY 308872 000005C1 10 16.1 13068 11627
5=Work with job
3. Display job run attributes, if active
Maximum temporary storage in megabytes . . . . . : *NOMAX
Temporary storage used . . . . . . . . . . . . : 112
Also, if your journalling all your data to the same journal, you might be
able to query the journal receiver for I/O's.
Centerfield technology had something called disk/hunter to do what you're
looking for. Any attempts to use their search function at their website
will result in an SQL error.
Disk/hunter also does not show in their list of products. Perhaps it's a
subset of another.