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
WRKSYSACT SEQ(*IO)<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.
This mailing list archive is Copyright 1997-2015 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact