|
Hiya, On 5 Feb 2004 at 12:08, jeff.glenn@xxxxxxxxxxxxxxxxxx wrote: > WRKSYSSTS > % CPU used . . . . . . : .1 System ASP . . . . . . : 580.5 G > Elapsed time . . . . . : 00:00:01 % system ASP used . . : 87.7792 > Jobs in system . . . . : 64877 Total aux stg . . . . : 580.5 G > % perm addresses . . . : .114 Current unprotect used : 32965 M > % temp addresses . . . : 1.374 Maximum unprotect . . : 33424 M Two possible culprits. Find the job that has the 30+ GB of temporary storage (when there is any one job). If it's not distributed among several system jobs, there's a good chance you could end it and free the disk space. As all jobs end at IPL, that also frees up the temp space. I'd also check your spoolfiles, with 64000+ jobs in system, I guess there'll be lots of spoolfiles. Journal receivers also tend to sum up to lots of disk space. But all this is only temporary cosmetics - prepare to buy some more DASD in the near future. Cleaning up all that stuff all the time fast costs more than the needed DASD. And with 80%+ used you're performace will suffer badly. Regards, Oliver
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.