V5R3，我确实可以访问 PASE 环境
磁盘空间报告显示用户目录占用了系统磁盘的 76%。遗憾的是，在目录中输入“8”并不能提供递归大小估计。
有没有其他命令或 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 中。
答案1
哇，我已经好几年没接触过 AS/400 了，而且我也没有使用过类似 Unix 的命令。
find问题中的命令仅搜索大型文件而不是大型目录（大量小文件）。
不要使用find命令，请尝试：
du /qibm/proddata | sort -n
如果可行，该列表的底部将成为该层次结构下最大的目录。
您还可以尝试对find列出的命令进行变体，查看目录的大小：
find /usr/share -type d -size +20000 -exec ls -lHd {} \; | awk '{ print $9 ": " $5 }'
您可以尝试使用不同的大小作为阈值。您的空间可能被 之外的文件占用/qibm/proddata。
不幸的是，我已经忘记了很多关于 AS/400 的知识。
答案2
首先，IBM 的关于该主题的知识库值得一读。
其次，这里存在一个巨大的误解。8在 IFS 文件夹上查看其属性，“磁盘大小”属性是 IFS“文件夹”对象的大小，除了任何其内容。因此，我们怀疑的文件夹的大小显示为 83 886 080 字节：80 兆字节。如果以递归方式计算，这还不算太糟，但这只是文件夹对象本身！一旦明确了这一点，解决方案就很简单了；使用 DEL 命令清除有问题的目录，该目录包含大约 75 GB 的对象。
导出 IFS 目录递归大小的一种方法是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 SELECT 将它们组合起来以掌握全局：
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/用户数据/OS400/MGTC/服务
如果此文件夹特别大，请按照IBM 的指示将其关闭（除非有特殊原因需要打开它），然后按上述方法清除目录。
最后，中端邮件列表档案以及相应的维基百科也是其领域中极好的资源。SQL 示例和有关管理中心跟踪的说明均来自 Midrange 邮件列表上的交流。