V5R3, I do have access to the PASE environment

Disk Space Report shows that User Directories are taking up 76% of the system disk. Unfortunately, putting an '8' on the directories does not give recursive size estimates.

Are there any other commands or IBM utilities that can efficiently get this information so that we can discover which folder is consuming the disk space? The system's already at a crawl, and I'd rather not bring it to a halt in the attempt to diagnose it.

IBM mentioned the following PASE utility:

find /qibm/proddata -type f -size +20000 -exec ls -lH {} \; | awk '{ print $9 ": " $5 }'

But it has (thus far) only returned ~3-4 GB worth of files, which leads me to believe that it's thousands of smaller files that are causing the system strain.

Worst case scenario, I'll run a SBMJOB tomorrow with QSH CMD('ls -R / >> /QSYS.LIB/QGPL.LIB/QSHOUT.FILE/QSHOUT.MBR') and just put it in QSYSNOMAX with a low priority.


2 Answers 2


Wow, it's been years since I touched an AS/400 and I didn't have Unix-like commands on it.

The find command in your question only searches for large files rather than large directories (lots of small files).

Instead of the find command, try:

du /qibm/proddata | sort -n

If that works, the bottom of that list is going to be the largest directories under that hierarchy.

You can also try a variation on the find command you listed which looks at the sizes of directories:

find /usr/share -type d -size +20000 -exec ls -lHd {} \; | awk '{ print $9 ": " $5 }'

You might try different sizes as your threshold. It might be possible that your space is being eaten up by files outside of /qibm/proddata.

Unfortunately, I've forgotten a lot of what I knew about the AS/400.

  • 1
    IBM added a 'PASE environment', which allows for a subset of Unix commands and the like. It's really nifty as it can be referenced by OS/400 applications, so you can write a utility that makes a call to a Unix app (ie., ghostscript for PDF conversion, for example) and return the result to your RPG application. /qibm/proddata was just an example, I was trying it folder-by-folder. I'll give du a shot, if it's available. df was not; as I said, limited subset. But it's worth a shot. Thank you. Oct 23, 2009 at 12:29
  • Correction: QSH is the restricted subset, PASE allows anything AIX does. Oct 27, 2009 at 20:53
  • This is the answer. What is marked as the "answer" is a byzantine way of doing it. As an aside, "du" stands for "Disk Usage".
    – Allen
    May 22, 2010 at 14:13
  • @Allen du is not necessarily available unless it is specifically installed; it wasn't available on the system I was working on. Dec 29, 2011 at 20:13

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:


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:


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.