如何计算 space 记录数
How to calculate space for number of records
我正在尝试使用以下公式计算数据集所需的 space，但是当我将它与系统中的现有数据集进行交叉检查时，我在某处出错了。请帮助我
第一个数据集：
记录格式。 . . : VB
记录长度。 . . : 445
块大小。 . . . : 32760
记录数......：51560
Using below formula to calculate
optimal block length (OBL) = 32760/record length = 32760/449 = 73
As there are two blocks on the track, hence (TOBL) = 2 * OBL = 73*2 = 146
Find number of physical records (PR) = Number of records/TOBL = 51560/146 = 354
Number of tracks = PR/2 = 354/2 = 177
But I can below in the dataset information
Current Allocation
Allocated tracks . : 100
Allocated extents . : 1
Current Utilization
Used tracks . . . . : 100
Used extents . . . : 1
第二个数据集：
记录格式。 . . : VB
记录长度。 . . : 445
块大小。 . . . : 27998
记录数......：127,252
Using below formula to calculate
optimal block length (OBL) = 27998/record length = 27998/449 = 63
As there are two blocks on the track, hence (TOBL) = 2 * OBL = 63*2 = 126
Find number of physical records (PR) = Number of records/TOBL = 127252/126 = 1010
Number of tracks = PR/2 = 1010/2 = 505
Number of Cylinders = 505/15 = 34
But I can below in the dataset information
Current Allocation
Allocated cylinders : 69
Allocated extents . : 1
Current Utilization
Used cylinders . . : 69
Used extents . . . : 1
对您的方法的一些观察。
首先，由于您处理的记录是可变长度的，因此了解“平均”记录长度会很有帮助，因为这有助于制定更准确的存储预测。您的方法假设所有记录都达到最大值的最坏情况，这对于规划目的来说很好，但实际上，如果记录长度的平均值低于最大值，您可能会看到实际分配会更低。
您采用的方法是合理的，但考虑到您可以告知 z/OS 块、记录、DASD 几何中的 space 要求或让 DFSMS 代表您执行计算。请参阅此 article 以获取有关选项的一些其他信息。
回到你的计算：
你的最佳块长度（OBL）实际上是每个块的记录数（RPB）。块大小除以最大记录长度得出可以存储在块中的全长记录数。如果您的平均记录长度更短，那么您可以在每个块中存储更多记录。
每个磁道两个块的假设可能适用于您的情况，但这取决于将用于基础分配的实际设备类型。这是支持的 DASD 设备及其几何结构的一些几何结构 link。
您假设每个轨道两个块取决于设备对于 3390 是不正确的，因为您需要 64k 用于一个轨道上的两个块，但是您可以看到 3390 的最大值为 56k，因此您只会得到一个块设备上的每个曲目。
此外，看起来您确实通过添加 4 个字节将 RDW 考虑在内，但是如果有人不熟悉 z/OS 上的 V 记录，那么看问题的人可能会感到困惑。在您的计算中在 27998 处每个块有 61 条记录（这是“最佳块长度”，因此两个块可以舒适地放在一条轨道上）。
我将使用以下值：
MaximumRecordLength = RecordLength + 4 for RDW
TotalRecords = 最大长度的总记录数（最坏情况）
BlockSize = 建模块大小
RecordsPerBlock = 一个块中可以容纳的记录数（最坏情况）
BlocksNeeded = 包含估计记录所需的块数（最坏情况）
BlocksPerTrack = 来自 IBM 设备几何信息
TracksNeeded = TotalRecords / RecordsPerBlock / BlocksPerTrack
柱面 = 每个柱面的设备轨道（大多数设备为 15 个）
Example 1:
Total Records = 51,560
BlockSize = 32,760
BlocksPerTrack = 1 (from device table)
RecordsPerBlock: 32,760 / 449 = 72.96 (72)
Total Blocks = 51,560 / 72 = 716.11 (717)
Total Tracks = 717 * 1 = 717
Cylinders = 717 / 15 = 47.8 (48)
Example 2:
Total Records = 127,252
BlockSize = 27,998
BlocksPerTrack = 2 (from device table)
RecordsPerBlock: 27,998 / 449 = 62.35 (62)
Total Blocks = 127,252 / 62 = 2052.45 (2,053)
Total Tracks = 2,053 / 2 = 1,026.5 (1,027)
Cylinders = 1027 / 15 = 68.5 (69)
现在，关于实际分配。这取决于你如何分配space，记录的大小。假设它在 JCL 中，您可以使用 SPACE= 的 RLSE 子参数在创建和关闭时释放 space。这应该释放未使用的资源。
鉴于记录是 V 可变的，估计是最坏的情况，您需要了解更多关于平均记录长度的信息，以了解根据实际 space 使用的实际分配。
最后的想法是，您正在做的所有工作都可以被您的存储管理员通过 ACS 例程覆盖。我相信今天大多数人会指定一个 BLKSIZE=0 并让 DFSMS 完成所有艰苦的工作，因为该组件有更多关于文件将去哪里、底层设备是什么以及最有效的分配方式的信息.磁盘几何和分配的日子更像是一个篝火晚会的故事，除非你的环境没有被管理来为你做这些事情。
与其尝试计算磁道或柱面，不如去计算 MB 或 KB。 z/OS (DFSMS) 会为您计算需要多少轨道或柱面。
在 JCL 中，它不是直接的，但也不是太复杂，一旦你明白了。
有个DD语句参数叫AVGREC=，就是触发器。让我为你上面的第一个案例做一个例子：
//anydd DD DISP=(NEW,CATLG),
// DSN=your.new.data.set.name,
// REFCM=VB,LRECL=445,
// SPACE=(445,(51560,1000)),AVGREC=U
//* | | | |
//* V V V V
//* (1) (2) (3) (4)
参数AVGREC=U (4) 告诉系统三件事：
- 首先，
SPACE=(1)中的第一个子参数应解释为平均记录长度。 （注意 该值完全独立于 LRECL= 中指定的值。）
- 其次，它告诉系统，第二个 (2) 和第三个 (3)
SPACE= 子参数是 平均长度的记录数 (1) 数据集应该能够存储。
- 第三，它告诉系统数字 (2) 和 (3) 在记录中 (
AVGREC=U)。备选方案有数千 (AVGREC=M) 和数百万 (AVGREC=M)。
因此，此 DD 语句将分配足够的 space 来容纳估计的记录数。您不必关心轨道容量、块容量、设备几何形状等。
给定您期望的记录数和（平均）记录长度，您可以轻松计算出所需的千字节数或兆字节数。不幸的是，您不能在 JCL 中直接指定 KB 或 MB，但有一种使用 AVGREC= 的方法，如下所示。
您的第一个数据集将获得 51560 条（最大）长度为 445 的记录，即 22'944'200 字节，或 ~22'945 KB，或 ~23 MB。以 KB 为单位分配的 JCL 如下所示：
//anydd DD DISP=(NEW,CATLG),
// DSN=your.new.data.set.name,
// REFCM=VB,LRECL=445,
// SPACE=(1,(22945,10000)),AVGREC=K
//* | | | |
//* V V V V
//* (1) (2) (3) (4)
您希望系统为 22945 (2) 千 (4) 条长度为 1 字节 (1) 的记录分配主要 space，即 22945 KB，为次要 space 分配 10' 000 (3) 千 (4) 条记录，长度为 1 字节 (1)，即 10'000 KB。
现在指定 MB 的相同分配：
//anydd DD DISP=(NEW,CATLG),
// DSN=your.new.data.set.name,
// REFCM=VB,LRECL=445,
// SPACE=(1,(23,10)),AVGREC=M
//* | | | |
//* V V V V
//* (1) (2)(3) (4)
您希望系统为 23 (2) 百万 (4) 条长度为 1 字节 (1) 的记录分配主要 space，即 23 MB，为次要 space 分配 10 ( 3) 数百万 (4) 条长度为 1 字节 (1) 的记录，即 10 MB。
我很少用后者以外的东西。
在 ISPF 中，它甚至更容易：数据集分配 (3.2) 允许 KB 和 MB 作为 space 单位（在所有旧单位中）。
使用 SPACE 和 AVGREC 等的一个有用且通常更简单的替代方法是简单地使用 space 的 DATACLAS，如果您的站点定义了适当大小的数据。如果您查看 ISMF 选项 4，您可以列出可用的 DATACLAS 并查看它们提供的 space 值等。您会期望看到许多大小范围，有些有或没有扩展格式 and/or 压缩。即使 DATACLAS 过度分配了一点，过度分配的 space 也可能会在收盘时或 space 管理期间由分配给数据集的 MGMTCLAS 释放。您确实可以选择对 DATACLAS AND SPACE 进行编码，在这种情况下，任何编码的 space（或其他）值都将覆盖 DATACLAS，这有助于处理异常。这仍然取决于您的存储管理员如何对 ACS 例程进行编码，但通常允许用户指定 DATACLAS，ACS 例程将遵守它。
对于基本的数据集大小计算，我只是使用 LRECL 乘以预期的最大记录数除以 1000 几次以获得粗略的 MB 数字。显然，变量 records/blks 为 RDW and/or BDW 每个添加 4 个字节，但除非记录数量很大或 DASD 对于 space 来说非常紧凑，否则它不应该足够重要。
例如
=(51560*445)/1000/1000 显示为 ~23MB
此外，不要指望您的分配完全符合您的要求，因为 Z/OS 上的最小分配是 1 首曲目或 ~56k。 BLKSIZE 还通过添加每块约 32 字节的块间间隙来生效。通过省略 BLKSIZE 或编码 BLKSIZE=0 调用 SDB（系统确定的块大小），它将始终尝试提供尽可能接近 28k 的半轨道阻塞，因此每个轨道两个块，这是最 space 效率最高的。这确实很重要，80 字节的 BLKSIZE 浪费了大约 80% 的具有块间间隙的轨道。 BLKSIZE 也是对磁盘执行 read/write 时的传输单位，因此通常越大越好，但有一些例外情况，例如 KSDS 通过密钥随机访问，这可能导致 OLTP 事务中的数据传输量超过预期。
我正在尝试使用以下公式计算数据集所需的 space，但是当我将它与系统中的现有数据集进行交叉检查时，我在某处出错了。请帮助我
第一个数据集：
记录格式。 . . : VB
记录长度。 . . : 445
块大小。 . . . : 32760
记录数......：51560
Using below formula to calculate
optimal block length (OBL) = 32760/record length = 32760/449 = 73
As there are two blocks on the track, hence (TOBL) = 2 * OBL = 73*2 = 146
Find number of physical records (PR) = Number of records/TOBL = 51560/146 = 354
Number of tracks = PR/2 = 354/2 = 177
But I can below in the dataset information
Current Allocation
Allocated tracks . : 100
Allocated extents . : 1
Current Utilization
Used tracks . . . . : 100
Used extents . . . : 1
第二个数据集：
记录格式。 . . : VB
记录长度。 . . : 445
块大小。 . . . : 27998
记录数......：127,252
Using below formula to calculate
optimal block length (OBL) = 27998/record length = 27998/449 = 63
As there are two blocks on the track, hence (TOBL) = 2 * OBL = 63*2 = 126
Find number of physical records (PR) = Number of records/TOBL = 127252/126 = 1010
Number of tracks = PR/2 = 1010/2 = 505
Number of Cylinders = 505/15 = 34
But I can below in the dataset information
Current Allocation
Allocated cylinders : 69
Allocated extents . : 1
Current Utilization
Used cylinders . . : 69
Used extents . . . : 1
对您的方法的一些观察。
首先，由于您处理的记录是可变长度的，因此了解“平均”记录长度会很有帮助，因为这有助于制定更准确的存储预测。您的方法假设所有记录都达到最大值的最坏情况，这对于规划目的来说很好，但实际上，如果记录长度的平均值低于最大值，您可能会看到实际分配会更低。
您采用的方法是合理的，但考虑到您可以告知 z/OS 块、记录、DASD 几何中的 space 要求或让 DFSMS 代表您执行计算。请参阅此 article 以获取有关选项的一些其他信息。
回到你的计算：
你的最佳块长度（OBL）实际上是每个块的记录数（RPB）。块大小除以最大记录长度得出可以存储在块中的全长记录数。如果您的平均记录长度更短，那么您可以在每个块中存储更多记录。
每个磁道两个块的假设可能适用于您的情况，但这取决于将用于基础分配的实际设备类型。这是支持的 DASD 设备及其几何结构的一些几何结构 link。
您假设每个轨道两个块取决于设备对于 3390 是不正确的，因为您需要 64k 用于一个轨道上的两个块，但是您可以看到 3390 的最大值为 56k，因此您只会得到一个块设备上的每个曲目。
此外，看起来您确实通过添加 4 个字节将 RDW 考虑在内，但是如果有人不熟悉 z/OS 上的 V 记录，那么看问题的人可能会感到困惑。在您的计算中在 27998 处每个块有 61 条记录（这是“最佳块长度”，因此两个块可以舒适地放在一条轨道上）。
我将使用以下值：
MaximumRecordLength = RecordLength + 4 for RDW
TotalRecords = 最大长度的总记录数（最坏情况）
BlockSize = 建模块大小
RecordsPerBlock = 一个块中可以容纳的记录数（最坏情况）
BlocksNeeded = 包含估计记录所需的块数（最坏情况）
BlocksPerTrack = 来自 IBM 设备几何信息
TracksNeeded = TotalRecords / RecordsPerBlock / BlocksPerTrack 柱面 = 每个柱面的设备轨道（大多数设备为 15 个）
Example 1:
Total Records = 51,560
BlockSize = 32,760
BlocksPerTrack = 1 (from device table)
RecordsPerBlock: 32,760 / 449 = 72.96 (72)
Total Blocks = 51,560 / 72 = 716.11 (717)
Total Tracks = 717 * 1 = 717
Cylinders = 717 / 15 = 47.8 (48)
Example 2:
Total Records = 127,252
BlockSize = 27,998
BlocksPerTrack = 2 (from device table)
RecordsPerBlock: 27,998 / 449 = 62.35 (62)
Total Blocks = 127,252 / 62 = 2052.45 (2,053)
Total Tracks = 2,053 / 2 = 1,026.5 (1,027)
Cylinders = 1027 / 15 = 68.5 (69)
现在，关于实际分配。这取决于你如何分配space，记录的大小。假设它在 JCL 中，您可以使用 SPACE= 的 RLSE 子参数在创建和关闭时释放 space。这应该释放未使用的资源。
鉴于记录是 V 可变的，估计是最坏的情况，您需要了解更多关于平均记录长度的信息，以了解根据实际 space 使用的实际分配。
最后的想法是，您正在做的所有工作都可以被您的存储管理员通过 ACS 例程覆盖。我相信今天大多数人会指定一个 BLKSIZE=0 并让 DFSMS 完成所有艰苦的工作，因为该组件有更多关于文件将去哪里、底层设备是什么以及最有效的分配方式的信息.磁盘几何和分配的日子更像是一个篝火晚会的故事，除非你的环境没有被管理来为你做这些事情。
与其尝试计算磁道或柱面，不如去计算 MB 或 KB。 z/OS (DFSMS) 会为您计算需要多少轨道或柱面。
在 JCL 中，它不是直接的，但也不是太复杂，一旦你明白了。
有个DD语句参数叫AVGREC=，就是触发器。让我为你上面的第一个案例做一个例子：
//anydd DD DISP=(NEW,CATLG),
// DSN=your.new.data.set.name,
// REFCM=VB,LRECL=445,
// SPACE=(445,(51560,1000)),AVGREC=U
//* | | | |
//* V V V V
//* (1) (2) (3) (4)
参数AVGREC=U (4) 告诉系统三件事：
- 首先，
SPACE=(1)中的第一个子参数应解释为平均记录长度。 （注意 该值完全独立于LRECL=中指定的值。） - 其次，它告诉系统，第二个 (2) 和第三个 (3)
SPACE=子参数是 平均长度的记录数 (1) 数据集应该能够存储。 - 第三，它告诉系统数字 (2) 和 (3) 在记录中 (
AVGREC=U)。备选方案有数千 (AVGREC=M) 和数百万 (AVGREC=M)。
因此，此 DD 语句将分配足够的 space 来容纳估计的记录数。您不必关心轨道容量、块容量、设备几何形状等。
给定您期望的记录数和（平均）记录长度，您可以轻松计算出所需的千字节数或兆字节数。不幸的是，您不能在 JCL 中直接指定 KB 或 MB，但有一种使用 AVGREC= 的方法，如下所示。
您的第一个数据集将获得 51560 条（最大）长度为 445 的记录，即 22'944'200 字节，或 ~22'945 KB，或 ~23 MB。以 KB 为单位分配的 JCL 如下所示：
//anydd DD DISP=(NEW,CATLG),
// DSN=your.new.data.set.name,
// REFCM=VB,LRECL=445,
// SPACE=(1,(22945,10000)),AVGREC=K
//* | | | |
//* V V V V
//* (1) (2) (3) (4)
您希望系统为 22945 (2) 千 (4) 条长度为 1 字节 (1) 的记录分配主要 space，即 22945 KB，为次要 space 分配 10' 000 (3) 千 (4) 条记录，长度为 1 字节 (1)，即 10'000 KB。
现在指定 MB 的相同分配：
//anydd DD DISP=(NEW,CATLG),
// DSN=your.new.data.set.name,
// REFCM=VB,LRECL=445,
// SPACE=(1,(23,10)),AVGREC=M
//* | | | |
//* V V V V
//* (1) (2)(3) (4)
您希望系统为 23 (2) 百万 (4) 条长度为 1 字节 (1) 的记录分配主要 space，即 23 MB，为次要 space 分配 10 ( 3) 数百万 (4) 条长度为 1 字节 (1) 的记录，即 10 MB。
我很少用后者以外的东西。
在 ISPF 中，它甚至更容易：数据集分配 (3.2) 允许 KB 和 MB 作为 space 单位（在所有旧单位中）。
使用 SPACE 和 AVGREC 等的一个有用且通常更简单的替代方法是简单地使用 space 的 DATACLAS，如果您的站点定义了适当大小的数据。如果您查看 ISMF 选项 4，您可以列出可用的 DATACLAS 并查看它们提供的 space 值等。您会期望看到许多大小范围，有些有或没有扩展格式 and/or 压缩。即使 DATACLAS 过度分配了一点，过度分配的 space 也可能会在收盘时或 space 管理期间由分配给数据集的 MGMTCLAS 释放。您确实可以选择对 DATACLAS AND SPACE 进行编码，在这种情况下，任何编码的 space（或其他）值都将覆盖 DATACLAS，这有助于处理异常。这仍然取决于您的存储管理员如何对 ACS 例程进行编码，但通常允许用户指定 DATACLAS，ACS 例程将遵守它。
对于基本的数据集大小计算，我只是使用 LRECL 乘以预期的最大记录数除以 1000 几次以获得粗略的 MB 数字。显然，变量 records/blks 为 RDW and/or BDW 每个添加 4 个字节，但除非记录数量很大或 DASD 对于 space 来说非常紧凑，否则它不应该足够重要。
例如
=(51560*445)/1000/1000 显示为 ~23MB
此外，不要指望您的分配完全符合您的要求，因为 Z/OS 上的最小分配是 1 首曲目或 ~56k。 BLKSIZE 还通过添加每块约 32 字节的块间间隙来生效。通过省略 BLKSIZE 或编码 BLKSIZE=0 调用 SDB（系统确定的块大小），它将始终尝试提供尽可能接近 28k 的半轨道阻塞，因此每个轨道两个块，这是最 space 效率最高的。这确实很重要，80 字节的 BLKSIZE 浪费了大约 80% 的具有块间间隙的轨道。 BLKSIZE 也是对磁盘执行 read/write 时的传输单位，因此通常越大越好，但有一些例外情况，例如 KSDS 通过密钥随机访问，这可能导致 OLTP 事务中的数据传输量超过预期。