The problem is that it might be temporary space in a job, e.g., a server job; and the space might be released when that server job ends or even recycles. It might be a big bunch of streamfiles in the IFS — someone might be storing their video collection in your system. It might be artifacts from recurring errors — huge numbers of AF-Authority Failure entries in the audit journal or any number of similar possibilities. The possibilities are almost endless.
The increase might be due to newly created objects in the normal /QSYS.LIB file system. If it is, you can always run DSPOBJD *ALL/*ALL to an outfile and query the result to review creation dates and times. Without knowing about your environment, it’s impossible to know if that will do you any good or if it will provide info that you can use; but it’s a simple start that’s available immediately to all systems.
The increase might be from a process that created a large number of spooled files. For example, a looping job can quickly create joblog spooled files if they are set for JOBMSGQFL(*PRTWRAP). Other conditions might result in spooled files being generated multiple times; these might be error conditions that happen over and over. You might use WRKOUTQ with the default of OUTQ(*ALL) to see if any queues have grown in a major way.
If a job is responsible for temporary storage, you might get lucky and find it through WRKACTJOB. Press F11=Display elapsed data. Move the cursor over to the AuxIO column and press F16=Resequence. That should put the top jobs at the top of the list. If the top is far out of line, investigate it. Also, try resequencing on the CPU column. It might not be the top job, but might be in the top ten.
But that will only tend to find temporary storage in active jobs. If the job has ended, you can’t get to it through WRKACTJOB.
The standard process would begin with running RTVDSKINF in batch. This creates a map of objects and space, and the eventual results can be reported with PRTDSKINF. However, it will only be useful for analysis if it is run on a periodic basis, perhaps weekly. A new run can be compared against a previous run to see what areas have changed in space usage.
A second pair of commands is RTVDIRINF and PRTDIRINF. If PRTDSKINF indicates that space usage is in directories, then those would be used to investigate them. RTVDIRINF should be run periodically just as RTVDSKINF would be.
Also, you might run DSPUSRPRF to list profiles to an outfile. If done regularly, you might be able to query records to find changes in the UPMXSU (Storage Used) attribute. By narrowing it down to a user profile, you might be able to review jobs that ran under that profile or objects created or changed by that profile.
Note that general user profiles should have a limit on the maximum storage allowed. You shouldn’t allow profiles to be created as MAXSTG(*NOMAX). Review your profiles and set allowed maximums for all non-system profiles. Set some value that might be 10% more than the current Storage Used is for each profile. This will stop jobs from running away when creating or updating permanent objects. It won’t be as helpful for temporary storage.
There are too many options really to cover well. There are really too many possibilities.
The only real solution is to be prepared. Take periodic snapshots of statistics. Set reasonable maximum values. Start auditing.
Trying to find out after it’s too late is too difficult.