First off, IBM's knowledge base on the subject is worth reading.
Secondly, there was a huge misconception at play here. When putting an 8 on an IFS folder to view its properties, the 'Size on disk' attribute is the size of the IFS 'folder' object, apart from any of its contents. Therefore, in this the size of the folders we suspected showed 83 886 080 bytes: 80 megabytes. This wouldn't be bad if it was calculated recursively, but this is just the folder object itself! Once this point was made clear, the solution was simple; use the DEL command to clear the offending directory, which had about 75 GB worth of objects.
A method to derive the recursive size of an IFS directory is to put a 2 on its parent directory, and then a 6 on the directory object in question; the number yielded will be for the folder object and all objects contained, including subfolders and their objects.
The RTVDIRINF and PRTDIRINF commands are also potentially useful, although in my case I did not require them.
A couple notes on these from my colleage:
The commands produce different files for each run – the output should be prefixed with something meaningful; top-level directory or similar. PRTDIRINF has a *DIR option that gives a listing of the space used for each directory. One could probably run a query like this to get a quicker overview:
SELECT sum(QEZALCSIZE), sum(QEZDTASIZE) FROM homeo
This will give the total size in directory /home.
Here is a more useful example, running against each directory's results.
SELECT sum(O.QEZALCSIZE), D.QEZDIRNAM1, D.QEZDIRIDX
FROM homed d join homeo o on d.qezdiridx = o.qezdiridx
GROUP BY d.qezdiridx, qezdirnam1
ORDER BY 1 desc, 3, 2
You can then combine them using UNION SELECTs to grasp the big picture:
SELECT sum(QEZALCSIZE), QEZDIRNAM1, homeD.QEZDIRIDX
FROM homed join homeo on homed.qezdiridx = homeo.qezdiridx
GROUP BY homed.qezdiridx, qezdirnam1
UNION
SELECT sum(QEZALCSIZE), QEZDIRNAM1, etcD.QEZDIRIDX
FROM etcd join etco on etcd.qezdiridx = etco.qezdiridx
GROUP BY tcd.qezdiridx, qezdirnam1
ORDER BY 1 desc, 3, 2
One common culprit is this directory:
/QIBM/UserData/OS400/MGTC/service
If this folder is exceptionally large, follow IBM's instructions for turning it off (unless there's a particular reason you have it on) and then purge the directory as above.
Finally, the Midrange mailing list archives and the corresponding wiki are wonderful resources in their realm, as well. The SQL samples and the note regarding Management Central Tracing both came from exchanges on the Midrange mailing list.
