2

FTP 到 MainFrame 时如何计算存储空间？有人告诉我 LRECL 将永远保持“80”。不知道如何根据文件大小动态计算 PRI 和 SEC ...

   QUOTE SITE LRECL=80 RECFM=FB CY PRI=100 SEC=100
4

2 回答 2

3

如果站点有 SMS，则不需要，但如果需要计算磁道数是文件大小（以字节为单位）除以 56,664，或者柱面数是文件大小（以字节为单位）除以849,960。在任何一种情况下，你都会四舍五入。

于 2012-05-21T13:51:05.613 回答
2

不幸的是，IBM 的 FTP 服务器不支持更新的记录数空间分配规范（JCL 参数 AVGREC=U/M/K 加上作为 SPACE 参数中第一个规范的记录长度）。

但是，还有另一种选择，那就是使用较少使用的 SPACE 参数之一 - 块大小规范。为简单起见，我将假设 3390 种磁盘类型和标准数据集。

对于固定长度的记录，您想要计算适合半个轨道（27994 字节）的最大数字，因为 z/OS 仅支持最大 32760 的块大小。由于您正在处理 80 字节的记录，因此该数字是27290. 将文件大小除以该数字，即可得出块数。然后在 SITE 服务器命令中，指定

SITE BLKSIZE=27920 LRECL=80 RECFM=FB BLOCKS=27920 PRI=calculated# SEC=a_little_extra

这相当于 SPACE=(27920,(calculated#,a_little_extra))。

z/OS 空间分配计算所需的磁道数并向上舍入到最近的磁道边界。

对于可变长度记录，如果您的阅读应用程序可以处理它，请始终使用 BLKSIZE=27994。我对阅读应用程序发出警告的原因是，即使在今天，来自 ISV 的应用程序仍然具有奇怪的硬编码最大可变长度块，例如 12K。

如果您正在处理 PDSE，请始终在规范中对可变长度使用 BLKSIZE=32760，对固定长度使用最接近的 32760（FB/80 为 32720），但根据 BLKSIZE=4096 计算要求。PDSE 的底层布局很奇怪。物理记录是 4096 字节，这是因为有一些线性数据集 VSAM 代码处理物理 I/O。

于 2012-05-22T15:15:53.500 回答