一次定义几百个 GDG 的正确方法
Proper way to define a few hundred GDGs at once
我的站点的一个做法是，当批处理周期开始时，我们会在 运行 任何程序之前分配将在整个 运行 中使用的所有 GDG 的新一代.
这意味着我们现在遇到的情况是，我们甚至在进程开始之前就分配了 500 多个文件。我的任务是想方设法让这个庞大的循环更有效率。我想知道我应该为这些分配走哪条路：
- 运行 1 个巨大的 IDCAMS 步骤，一次制作所有新版本（当前功能）
- 将分配分解为仅分配一部分文件的多个 IDCAMS 步骤
连续多次调用 IDCAMS 的开销大吗？
我有一种预感，将这些分解成更小的步骤可以提高整体性能，但我真的没有明确的方法来测试它。我们的测试环境并不是 运行 指标的好地方，因为我们的工作通常以 JES 中的低优先级结束，所以我们经常跳来跳去，所以经过的时间并不是实际情况的好指标发生了，因为这些是 IDCAMS 分配，所以 CPU 统计数据总是很低。
TLDR；有谁知道哪个效率更高，或者我怎样才能找到哪个效率更高？
事实是，如果操作得当，定义数百个数据集不会给大多数现代 z/OS 系统带来压力。每个分配都经过一个可预测的系统服务序列——目录功能、分配功能、安全、SMF 日志记录等等——虽然肯定存在细微差别，但无论您如何操作，每个分配所花费的时间都相当相似。
根据经验，在现代平均调谐大型机上，典型的新文件分配不应超过 100 毫秒。如果分配您的 500 个数据集花费的时间可能超过一分钟，则您可能遇到了与您使用 IDCAMS 无关的问题。
举个例子，您的工作可能会陷入低优先级 class，一旦消耗一定数量的资源，它就会急需资源……在这种情况下，它可能只是在等待，而不是在等待dispatched（CPU 时间除以运行时间的简单计算将告诉您这是否是问题所在）。如果这是你的问题，那么 "cheat" 的一种常见方法是在 JCL 中定义 GDG 而不是通过 IDCAMS ...你的 JCL 分配发生在批处理启动器的优先级，通常高于作业一步本身。请记住，这意味着错误将导致 JCL 错误，而不是您可能从 IDCAMS 中的错误中获得的非零 return 代码。
您可能还想检查您的 GDG 基本定义 - 保持大量的世代往往会减慢速度......也许您可以想出一个更好的方案来存储更少的世代总数。
要做的一件事是确保您的系统程序员已经做好了适当的调整工作，尤其是目录环境...有许多参数可以控制缓存、缓冲等等，并且有一个适当的如果您想要良好的性能，调整目录是必不可少的。 this IBM document. 中有很多有用的信息 大多数任务都需要特殊授权，所以这可能是您无法自行处理的事情。
如果您实际上是为新数据集分配磁盘 space，您还需要确保您的分配参数是正确的。例如，如果您将大量数据集放在同一个磁盘卷上，这将是一件坏事。分配在卷级别进行大量序列化，因此这意味着您可以将数据集分布在多个磁盘卷上的次数越多，争用的可能性就越小。您可以使用 RMF（或您的站点可能拥有的任何供应商产品）之类的工具来监控入队延迟等 - 这通常是分配性能缓慢的罪魁祸首。
这是一个迭代过程，如果您真的想要有条不紊地处理它，请创建一个测试作业来分配一堆 GDG 文件并收集其性能统计信息。不同的分配参数和系统设置会给您带来不同的吞吐量，您会希望找到最佳组合而不是猜测。无论您使用了多少时间，您都可以获得 CPU 和 I/O 的服务单位计数，这些是您找出最有效方法的最佳指南。
一旦您确信系统已正确调整并且没有发生不必要的延迟，下一个选择是您是否要通过并行性等技术以 CPU 利用率换取更好的运行时间。您所做的主要是 I/O 绑定工作，因此假设您的系统调整良好，将您的单个作业拆分为具有文件子集的多个作业将使用稍微多一点的处理器资源，但会 运行从经过时间的角度来看要快得多。最好的情况是当您 运行 处理器引擎不足时，或者当您将目录或磁盘驱动到高利用率时。
假设您的站点允许它们 运行 并行（也就是说，有足够的批处理启动器等），将您的分配分成多个作业是实现并行的简单途径。如果您这样做并且所用时间不比 运行 完成一项大作业好，那么是时候深入研究并研究争用的地方了，正如我在上面解释的那样。
如果你想来点冒险，并行进行大量分配的一个好方法是使用 UNIX 服务 shell 和类似 BPXWDYN 的东西而不是 IDCAMS（一定要指定 GDGNT标记为 BPXWDYN）。如果操作得当，您可以自己编写一个 shell 脚本来启动任意数量的子进程，每个子进程执行您分配的一部分。如果配置得当，这具有 运行 在一个大地址 space 中运行的优势，而不是需要多个地址 space 才能实现并行性的批处理作业。
我的站点的一个做法是，当批处理周期开始时，我们会在 运行 任何程序之前分配将在整个 运行 中使用的所有 GDG 的新一代.
这意味着我们现在遇到的情况是，我们甚至在进程开始之前就分配了 500 多个文件。我的任务是想方设法让这个庞大的循环更有效率。我想知道我应该为这些分配走哪条路：
- 运行 1 个巨大的 IDCAMS 步骤，一次制作所有新版本（当前功能）
- 将分配分解为仅分配一部分文件的多个 IDCAMS 步骤
连续多次调用 IDCAMS 的开销大吗？
我有一种预感，将这些分解成更小的步骤可以提高整体性能，但我真的没有明确的方法来测试它。我们的测试环境并不是 运行 指标的好地方，因为我们的工作通常以 JES 中的低优先级结束，所以我们经常跳来跳去，所以经过的时间并不是实际情况的好指标发生了，因为这些是 IDCAMS 分配，所以 CPU 统计数据总是很低。
TLDR；有谁知道哪个效率更高，或者我怎样才能找到哪个效率更高？
事实是，如果操作得当，定义数百个数据集不会给大多数现代 z/OS 系统带来压力。每个分配都经过一个可预测的系统服务序列——目录功能、分配功能、安全、SMF 日志记录等等——虽然肯定存在细微差别，但无论您如何操作，每个分配所花费的时间都相当相似。
根据经验，在现代平均调谐大型机上，典型的新文件分配不应超过 100 毫秒。如果分配您的 500 个数据集花费的时间可能超过一分钟，则您可能遇到了与您使用 IDCAMS 无关的问题。
举个例子，您的工作可能会陷入低优先级 class，一旦消耗一定数量的资源，它就会急需资源……在这种情况下，它可能只是在等待，而不是在等待dispatched（CPU 时间除以运行时间的简单计算将告诉您这是否是问题所在）。如果这是你的问题，那么 "cheat" 的一种常见方法是在 JCL 中定义 GDG 而不是通过 IDCAMS ...你的 JCL 分配发生在批处理启动器的优先级，通常高于作业一步本身。请记住，这意味着错误将导致 JCL 错误，而不是您可能从 IDCAMS 中的错误中获得的非零 return 代码。
您可能还想检查您的 GDG 基本定义 - 保持大量的世代往往会减慢速度......也许您可以想出一个更好的方案来存储更少的世代总数。
要做的一件事是确保您的系统程序员已经做好了适当的调整工作，尤其是目录环境...有许多参数可以控制缓存、缓冲等等，并且有一个适当的如果您想要良好的性能，调整目录是必不可少的。 this IBM document. 中有很多有用的信息 大多数任务都需要特殊授权，所以这可能是您无法自行处理的事情。
如果您实际上是为新数据集分配磁盘 space，您还需要确保您的分配参数是正确的。例如，如果您将大量数据集放在同一个磁盘卷上，这将是一件坏事。分配在卷级别进行大量序列化，因此这意味着您可以将数据集分布在多个磁盘卷上的次数越多，争用的可能性就越小。您可以使用 RMF（或您的站点可能拥有的任何供应商产品）之类的工具来监控入队延迟等 - 这通常是分配性能缓慢的罪魁祸首。
这是一个迭代过程，如果您真的想要有条不紊地处理它，请创建一个测试作业来分配一堆 GDG 文件并收集其性能统计信息。不同的分配参数和系统设置会给您带来不同的吞吐量，您会希望找到最佳组合而不是猜测。无论您使用了多少时间，您都可以获得 CPU 和 I/O 的服务单位计数，这些是您找出最有效方法的最佳指南。
一旦您确信系统已正确调整并且没有发生不必要的延迟，下一个选择是您是否要通过并行性等技术以 CPU 利用率换取更好的运行时间。您所做的主要是 I/O 绑定工作，因此假设您的系统调整良好，将您的单个作业拆分为具有文件子集的多个作业将使用稍微多一点的处理器资源，但会 运行从经过时间的角度来看要快得多。最好的情况是当您 运行 处理器引擎不足时，或者当您将目录或磁盘驱动到高利用率时。
假设您的站点允许它们 运行 并行（也就是说，有足够的批处理启动器等），将您的分配分成多个作业是实现并行的简单途径。如果您这样做并且所用时间不比 运行 完成一项大作业好，那么是时候深入研究并研究争用的地方了，正如我在上面解释的那样。
如果你想来点冒险，并行进行大量分配的一个好方法是使用 UNIX 服务 shell 和类似 BPXWDYN 的东西而不是 IDCAMS（一定要指定 GDGNT标记为 BPXWDYN）。如果操作得当，您可以自己编写一个 shell 脚本来启动任意数量的子进程，每个子进程执行您分配的一部分。如果配置得当，这具有 运行 在一个大地址 space 中运行的优势，而不是需要多个地址 space 才能实现并行性的批处理作业。