V5R3，我可以访问PASE环境
磁盘空间报告显示用户目录占用了系统磁盘的76％。 不幸的是，在目录中放置一个“8”并不能给出recursion大小估计。
是否有任何其他命令或IBM实用程序可以有效地获取此信息，以便我们可以发现哪个文件夹占用磁盘空间？ 该系统已经在爬行，我宁愿不要试图诊断它停下来。
IBM提到了下面的PASE工具：
CALL QP2TERM
find /qibm/proddata -type f -size +20000 -exec ls -lH {} \; | awk '{ print $9 ": " $5 }'
但它（迄今为止）只返回了大约3-4 GB的文件，这使我相信，成千上万个较小的文件会导致系统紧张。
在最坏的情况下，我将使用QSH CMD（'ls -R / >> /QSYS.LIB/QGPL.LIB/QSHOUT.FILE/QSHOUT.MBR'）运行一个SBMJOB，并将它放在QSYSNOMAX中。
哇，我碰了一个AS / 400已经有好几年了，而且我没有类Unix的命令。
您的问题中的find命令只search大文件，而不是大目录（大量的小文件）。
而不是find命令，请尝试：
du /qibm/proddata | sort -n
如果这样的话，这个列表的底部将是该层次结构下最大的目录。
你也可以尝试一下你所列出的find命令的variables，查看目录的大小：
find /usr/share -type d -size +20000 -exec ls -lHd {} \; | awk '{ print $9 ": " $5 }'
你可以尝试不同的尺寸作为你的门槛。 你的空间可能被/qibm/proddata以外的文件/qibm/proddata 。
不幸的是，我忘记了很多关于AS / 400的知识。
首先，IBM 关于这个主题的知识库值得一读。
其次，在这里玩了一个很大的误解。 当在IFS文件夹上放置一个8来查看它的属性时， 'Size on disk'属性是IFS'文件夹'对象的大小，除了它的任何内容 。 因此，在这个我们怀疑的文件夹的大小显示83 886 080字节：80兆字节。 如果是recursion计算，这并不坏，但这只是文件夹对象本身！ 一旦明确了这一点，解决办法很简单; 使用DEL命令清除违规的目录，其中有大约75 GB的对象。
导出IFS目录的recursion大小的方法是在其父目录上放置2 ，然后在目录对象上放置6 ; 产生的数字将用于文件夹对象和包含的所有对象，包括子文件夹及其对象。
RTVDIRINF和PRTDIRINF命令也是有用的，虽然在我的情况下我不需要它们。
有一对夫妇从我的同事那里注意到：
这些命令为每次运行产生不同的文件 – 输出应该以有意义的前缀为前缀; 顶级目录或类似的。 PRTDIRINF有一个* DIR选项，列出每个目录使用的空间。 我们可以运行一个这样的查询来获得更快的概述：
SELECT sum(QEZALCSIZE), sum(QEZDTASIZE) FROM homeo
这将在目录/ home中给出总大小。
这是一个更有用的例子，针对每个目录的结果运行。
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
然后，您可以使用UNION SELECTs将它们组合起来，以抓住大局：
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
一个常见的罪魁祸首是这个目录：
/ QIBM /的UserData / OS400 / MGTC /服务
如果这个文件夹特别大，请按照IBM的说明closures它（除非有特殊原因），然后清除上面的目录。
最后， Midrange邮件列表档案和相应的wiki也是他们领域的精彩资源。 SQL示例和有关Management Central Tracing的注释都来自Midrange邮件列表上的交换。