jcl - JCL ICEMAN需要多少个排序文件？

我正在使用JCL，并且有一个所谓的 ICEMAN ，它在使用IBM SORT实用程序DFSORT时被调用。 DFSORT可以用于SORT，COPY或MERGE文件等。在下面的示例中，输出来自SORT。我的问题是需要多少个排序文件(// SORTWK01 DD UNIT = SYSDA，SPACE =(CYL，30))文件。在我看来，当他们在JCL中看到它们时，它们的数量总是在变化。是否有一个公式可以计算需要多少SORTWKnns的大小？

JCL代码:

//STEP5    EXEC PGM=ICEMAN,COND=(4,LT)
//SYSOUT    DD  SYSOUT=1
//SYSIN     DD  DSN=CDP.PARMLIB(cardnumberhere),DISP=SHR
//SORTIN    DD  DSN=filename,DISP=SHR
//SORTOUT   DD  DSN=filename,DISP=(OLD,KEEP),
//          DCB=(LRECL=5000,RECFM=FB),
//          SPACE=(CYL,30)
//SORTWK01  DD  UNIT=SYSDA,SPACE=(CYL,30)
//SORTWK02  DD  UNIT=SYSDA,SPACE=(CYL,30)
//SORTWK03  DD  UNIT=SYSDA,SPACE=(CYL,30)
//SORTWK04  DD  UNIT=SYSDA,SPACE=(CYL,30)

最佳答案

EXEC PGM=ICEMAN

和

EXEC PGM=SORT

将给您相同的结果。它们彼此是ALIAS，并且无论指定哪个PGM =都执行相同的程序。

正如cschneid所指出的那样，SORTWKnn是“排序工作数据集”，并且在不参考现有“标准”数据集的情况下复制JCL的趋势导致工作数据集空间的大量过度分配。

可以通过两种方式指定SORT的工作区，手动指定(放入SORTWKnn文件，最大数量远远超过15)或动态使用DYNALLOC。

DYNALLOC是推荐的方法，因为工作空间将根据SORT所需要的进行分配。还要在OPTION语句上查找关联的安装选项/替代。

通常，将有默认的DYNALLOC值处理大多数SORT步骤，然后为异常大的SORT提供特定的OPTION参数。

在作业步骤中手动定义SORTWKnn数据集将“关闭”该步骤的任何动态分配。

SORTWKnn数据集的特定定义有时很方便，但并不经常。这些天所需的空间可能接近输入文件的1.2倍。您可以从特定作业步骤的典型运行中检查SYSOUT，并查看实际使用了多少空间，如果存在过度分配/分配不足的情况，则可以调整主要SORTWKnn空间或数据集的数量以使其更适合。

当DYNALLOC用于由编程语言调用的SORT时，指定其他信息(平均记录长度，估计的记录数)通常是个好主意。这是因为SORT可能无法“看到”输入数据集，因此没有太多信息来估计所需的工作空间。

另外，最好将所有DCB信息保留在输出文件中。 SORT将提供来自输入数据集的正确DCB信息，并考虑对SORT控制卡中数据的任何处理。如果将DCB信息保留在JCL(LRECL，RECFM)中，则只要有文件更改，就有两个地方可以更改它，而不是一个。

在您的实际示例中，在运行步骤时不必要地分配了100个以上的柱面空间。这种类型的事物在应用于许多JOB时，可能导致其他JOB出现故障，甚至导致不必要的额外DASD(磁盘空间)的购买/收费。

关于jcl - JCL ICEMAN需要多少个排序文件？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/20955706/