mainframe - 一次定义数百个GDG的正确方法

Question

在我的站点上，一种实践是当一个批处理周期开始时，我们在运行任何程序之前分配所有将在整个运行中使用的所有GDG的新一代。

这意味着我们现在遇到的情况是，甚至在我们的流程开始之前就分配了500多个文件。我的任务是设法使这一巨大的循环更有效率。我想知道应该为这些分配走哪条路：


运行1个巨大的IDCAMS步骤并立即制作所有新版本（当前功能）
将分配分为多个IDCAMS步骤，这些步骤仅分配一部分文件


多次背靠背拨打IDCAMS有很多麻烦吗？

我有一种直觉，认为将这些分解成较小的步骤可以提高整体性能，但是我真的没有明确的方法来测试它。我们的测试环境并不是运行指标的好地方，因为我们的工作通常在JES中以较低的优先级结束，因此我们经常被跳出来，因此经过的时间并不是真正发生实际情况的良好指标，并且这些是IDCAMS分配，无论如何，CPU统计信息总是很低。

TLDR；有谁知道哪个更有效，或者我如何找到哪个更有效？

Answer 1

事实是，定义数百个数据集如果正确完成，就不会给大多数现代z / OS系统带来压力。每种分配都经过可预测的系统服务序列-目录功能，分配功能，安全性，SMF日志记录等-尽管当然存在细微的差异，但是无论您如何操作，每种分配都需要相当长的时间。

根据经验，在现代的平均调谐大型机上，典型的新文件分配不应超过100毫秒。如果要花超过一分钟的时间来分配500个数据集，则可能是与IDCAMS的使用无关的错误。

举个例子，您的工作可能属于低优先级的类别，一旦消耗了一定数量的资源便会饿死资源...在这种情况下，它可能只是在等待而不是被分派（CPU时间的简单计算除以时间流逝会告诉您这是否是问题所在）。如果这是您的问题，那么“欺骗”的一种常见方法是在JCL中定义GDG，而不是通过IDCAMS ...您的JCL分配是在批处理启动程序的优先级上进行的，该优先级通常高于作业步骤本身。请记住，尽管这意味着错误将导致JCL错误，而不是IDCAMS中的错误可能导致的非零返回码。

您可能还需要检查您的GDG基本定义-保持大量世代会降低速度...也许您可以提出一种更好的方案来存储更少的总世代。

要做的一件事是确保您的系统程序员在调优事情方面做得很好，尤其是目录环境...有许多参数可以控制缓存，缓冲等，并且如果要对目录进行适当调优，则必须进行适当调优你想要好的表现。 this IBM document.中有很多很好的信息，大多数任务需要特殊的授权，因此这可能是您无法独自处理的。

如果您实际上是在为新数据集分配磁盘空间，则还需要确保分配参数正确。例如，如果要将大量数据集放在同一磁盘卷上，那将是一件坏事。分配在卷级别进行了大量序列化，因此，您可以将数据集分布在多个磁盘卷上的次数越多，争用的机会就越少。您可以使用RMF之类的工具（或您的站点可能提供的任何供应商产品）监视排队延迟等等，这通常是导致分配性能缓慢的元凶。

这是一个反复的过程，如果您真的想对它有条不紊，请创建一个测试作业，该作业分配一堆GDG文件并收集其性能统计信息。不同的分配参数和系统设置将为您提供不同的吞吐量，并且您将希望采用最佳组合而不是猜测。无论您经过多少时间，都可以获取CPU和I / O的服务单元计数，这是确定最佳方法的最佳指南。

一旦您确信系统已正确调整并且没有不必要的延迟发生，那么下一个选择就是是否要通过诸如并行性之类的技术来将CPU利用率换来更好的经过时间。您正在执行的工作主要是I / O绑定工作，因此，假设您的系统调整良好，将单个作业拆分为多个包含文件子集的作业将使用更多的处理器资源，但运行时间会更快观点看法。最好的情况是处理器处理器用完了，或者驱动目录或磁盘达到高利用率。

假设您的站点允许它们并行运行（即，有足够的批处理启动器等），则将分配分成多个作业是实现并行性的简单途径。如果您这样做，并且经过的时间并不比完成一项大工作好，那么该是时候深入研究竞争的位置了，正如我在上面解释的那样。

如果您想冒险一点，那么并行进行大量分配的一种不错的方法是使用UNIX Services shell和类似BPXWDYN之类的东西而不是IDCAMS（一定要为BPXWDYN指定GDGNT标志）。正确完成后，您可以编写自己的Shell脚本来启动任何数量的子进程，每个子进程都进行分配的子集。正确配置后，它的优点是可以在一个大地址空间中运行，而不是需要多个地址空间才能实现并行的批处理作业。