|
查看上一个主题 :: 查看下一个主题
|
| 作者 |
信息 |
srajendran2
新的用户
已加入：2008年5月13日
帖子：56
地点：钦奈
|
|
|
|
当前，程序/ JCL正在创建VBS文件，并且必须根据客户的请求将其更改为VB文件。下面给出了COBOL和JCL上的代码。如果我在JCL中将录制模式更改为“ V”并将VBS更改为VB，它将起作用吗？还是我应该照顾程序或JCL中的其他内容？
科宝
| 码： |
FD SYS230-VAR-OUT
记录取决于800-SYS230-RDW
RECORDING MODE IS S
标签记录是标准的
阻止包含0个记录
数据记录为SYS230-VAR-OUT-REC。
01 SYS230-VAR-OUT-REC.
05 PIC X(01)发生1到32756次
取决于800-SYS230-RDW。
|
JCL
| 码： |
// SYS230 DD DSN=TEST.OUTPUT,
// DISP=(,CATLG,DELETE),
// SPACE=(CYL,(1,1),RLSE),
// DCB=(RECFM = VBS，LRECL = 32760，BLKSIZE = 32760)
|
我看到了与此相关的帖子。但是它只是提到将JCL从VBS更改为VB，而没有提到记录模式。 |
|
| 回到顶部 |
|
 |
罗伯特·桑普
全球主持人
已加入：2008年6月6日
帖子：8569
地点：美国爱荷华州迪比克
|
|
|
|
| 引用： |
| 如果我在JCL中将录制模式更改为“ V”并将VBS更改为VB，它将起作用吗？ |
应该，但是请注意，数据集的大小可能会大大增加。 VBS数据集的块中未使用的字节数不超过4个字节，而VB数据集的块中可能具有几乎LRECL的未使用字节数。具体情况将取决于数据，但预计需要增加的空间。 |
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
BLKSIZE = 32760是磁盘的不佳选择。您仅获得每条轨道的一条物理记录，并且不会使用该轨道的35％或40％。大多数加载模块数据集为RECFM = U，BLKSIZE = 32760。这有两个原因。- 您很少找到32K记录，更不用说接近32K的记录了。在大多数情况下，长文本记录之后将是一个或多个256字节记录；这些记录通常与文本记录相关，尽管最后一个记录将包含有关下一个文本记录的信息。
- 活页夹比您想象的文本记录大小要聪明。例如，如果看到磁道上的剩余空间为12K，它将写入12K记录。这个未记录的功能给我留下了深刻的印象，但是我对此也有疑问。当我发现活页夹正在做什么时，我为FB或VB数据集编写了PDS副本，从而复制了此功能。效果很好，但是实际数据集的净节省却比我希望的要少。我不使用该程序。
RECFM = VB，LRECL = 32760，BLKSIZE = 32760将不被接受。在VB中，必须为BDW（块描述符字）留出4个字节。对于BLKSIZE = 32760，您可以指定的最大LRECL为32756。同样要记住，对于RECFM = VB或VBS，LRECL指定数据集中的最大记录。许多记录可以更小。 SMF是RECFM = VBS的主要用户。它以RECFM = VBS，LRECL = 32767开始，但是大多数记录要小得多。也许这个问题已经解决，但是您不能在JCL中指定LRECL = 32767，尽管DCB宏当然会接受它。
回到LRECL；我的程序之一指定RECFM = VB，LRECL = 4100。 19年前，当我设计该程序时，就想到了长期使用。它从未实现。实际上，最长的记录是120或130字节，但是LRECL从未改变。它不需要改变。 |
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
| 罗伯特·萨普（Robert Sample）写道： |
| 引用： |
| 如果我在JCL中将录制模式更改为“ V”并将VBS更改为VB，它将起作用吗？ |
应该，但是请注意，数据集的大小可能会大大增加。 VBS数据集的块中未使用的字节数不超过4个字节，而VB数据集的块中可能具有几乎LRECL的未使用字节数。具体情况将取决于数据，但预计需要增加的空间。 |
Sample先生说的不是VBS空间使用情况。 VBS有两个目标。- 写入大小恒定的物理记录（最后一条物理记录除外）。
- 为了在第一个项目符号中实现该目标，如果一条记录无法放入当前的物理记录中，则它将被打破并“扩展”到下一个物理记录中。每个记录段都有一个4字节的描述符。适用于一个物理设备的逻辑记录的描述符只是常规的VB RDW。跨越多个物理记录的记录的每个段的描述符都类似于RDW。它具有标志来指示它是第一个段，一个段是继续到下一个物理记录的中间段或一个段是最后一个段。
|
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
我创建了这个数据集。
| 码： |
列出的writevbs.output
XXXXXX.WRITEVBS.OUTPUT
--RECFM-LRECL-BLKSIZE-DSORG
VBS 32767 4096 PS
--VOLUMES--
XXXX25 |
我写了一个32767字节的记录到数据集。它具有此逻辑视图-
| 码： |
***记录1
0000 0 7FFF0000 11111111 11111111 11111111 *"...............*
0010 16 11111111 11111111 11111111 11111111 *................*
一条或多条线与上一条线相同
7FF0 32752 11111111 11111111 11111111 111111 *............... * |
开头的4个字节是RDW（记录描述符字）； 7FFF是记录长度32767。物理记录是-
| 码： |
***记录1
0000 0 10000000 0FFC0100 11111111 11111111 *................*
0010 16 11111111 11111111 11111111 11111111 *................*
一条或多条线与上一条线相同
0FF0 4080 11111111 11111111 11111111 11111111 *................*
***记录2
0000 0 10000000 0FFC0300 11111111 11111111 *................*
0010 16 11111111 11111111 11111111 11111111 *................*
一条或多条线与上一条线相同
0FF0 4080 11111111 11111111 11111111 11111111 *................*
...
***记录9
0000 0 00430000 003F0200 11111111 11111111 *................*
0010 16 11111111 11111111 11111111 11111111 *................*
一条或多条线与上一条线相同
0040 64 111111 *... * |
10000000是BDW（块描述符字）1000，当然是4096，记录中的字节数。
记录1中的0FFC0100被正确地称为段描述符字（SDW）。01是代码，表示它是较长逻辑记录的第一段。
记录2中的0FFC0300是SDW，表示该段是生成记录的中间段。
记录9中的003F0200是SDW，表示该段包含63个字节，并且是最后一个段。
BDW和SDW数据是开销，但是说它们被浪费或无用不是事实。 |
|
| 回到顶部 |
|
|
srajendran2
新的用户
已加入：2008年5月13日
帖子：56
地点：钦奈
|
|
|
|
感谢大家的答复。
不用在JCL和COBOL中将VBS更改为VB，而是可以在创建VBS并将其复制到VB之后仅使用SORT吗？它会给出相同的结果吗？ |
|
| 回到顶部 |
|
|
srajendran2
新的用户
已加入：2008年5月13日
帖子：56
地点：钦奈
|
|
|
|
| 我认为我们无法直接将VBS转换为VB，因为记录范围很广。 |
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
| srajendran2写道： |
| 我认为我们无法直接将VBS转换为VB，因为记录范围很广。 |
否。只要输出LRECL为>=与输入LRECL相比，IEBGENER或类似实用程序应该没有问题。实际上，只要最长的输入记录是<=输出LRECL应该没问题。 |
|
| 回到顶部 |
|
|
马索
REXX主持人
已加入：2006年3月13日
帖子：1348
地点：以色列
|
|
|
|
| srajendran2写道： |
| 不用在JCL和COBOL中将VBS更改为VB，而是可以在创建VBS并将其复制到VB之后仅使用SORT吗？它会给出相同的结果吗？ |
至少可以这样说，这是不明智的：您将花费宝贵的CPU时间而不花钱，并且（超过）该文件所需的磁盘空间的两倍。
只需更新您的程序和JCL。 |
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
| 马索写道： |
| srajendran2写道： |
| 不用在JCL和COBOL中将VBS更改为VB，而是可以在创建VBS并将其复制到VB之后仅使用SORT吗？它会给出相同的结果吗？ |
至少可以这样说，这是不明智的：您将花费宝贵的CPU时间而不花钱，并且（超过）该文件所需的磁盘空间的两倍。
只需更新您的程序和JCL。 |
估计数据集的大小增加比Marso认为的困难得多。如前所述，BLKSIZE不适合3390。更合适的BLKSIZE（例如27998）可能会使数据集大小减少40％。转换为VB的问题是逻辑记录长度的实际分配。我们不知道。我怀疑srajendran2知道这一点。我们所知道的是定义的LRECL，它指定了 最大 可能的记录长度。在实际的VB或VBS数据集中，实际的最大记录长度通常远小于最大长度。 srajendran2应该尽快确定 实际 数据集中的最大记录长度。实际上，今天最好！ |
|
| 回到顶部 |
|
|
罗伯特·桑普
全球主持人
已加入：2008年6月6日
帖子：8569
地点：美国爱荷华州迪比克
|
|
|
|
| 引用： |
| 在实际的VB或VBS数据集中，实际的最大记录长度通常远小于最大记录长度 |
对于VB，这是正确的。但是，我已经使用了VBS数据集（顺便说一下，不是SMF），并且可以肯定地说（看过块长条形图），磁盘上的VBS数据集的每个块长都在4字节之内。 BLKSIZE值。当z / OS填充VBS数据集的块时，只要块中剩余5个或更多字节（SDW为4个字节，数据记录为至少1个字节），就会创建一个起始段。这个特定的项目有一段时间了，但是我无法想象VBS的行为会发生太大的变化。 |
|
| 回到顶部 |
|
|
罗伯特·桑普
全球主持人
已加入：2008年6月6日
帖子：8569
地点：美国爱荷华州迪比克
|
|
|
|
| 更新：我已在我的z / OS 2.1系统上确认，带有RECFM = VBS，LRECL = 32760，BLKSIZE = 27998的SMF数据集除最后一个字节外，所有块的长度都在27994和27998字节之间。因此，自从我第一次观察时，VBS的行为就没有改变。 |
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
VBS设计的目的是具有基本恒定长度的物理记录。 Sample先生只是说IBM成功了。
VBS是在IBM推出RPS（2305和3330）磁盘以提高原始System / 360磁盘相对令人失望的性能的同时出现的。固定长度记录最初被认为很重要，因此RPS计算将正确显示，因此VBS被视为重要（请参见脚注）。
正常的VB将具有可变长度的物理记录。差异取决于数据集中逻辑记录的特征。这没有错。
昨天我花了一些时间编写一个程序来报告此情况。通过该程序运行各种数据集，报告的物理记录之间的差异很小。然后我意识到我没有包括最后的身体记录！结果表明存在明显的尺寸差异。但是，那么，有人希望最后一个物理记录要比其他记录小，因此将其包括在样本中可能不是一个好主意。
--------
事实证明，这种RPS计算非常愚蠢。顺序数据集确定了下一条记录在读取记录时的RPS编号；它不需要计算任何东西。
仿真3390似乎忽略了setector命令，并且似乎使用read扇区命令返回了垃圾。 |
|
| 回到顶部 |
|
|
|
|
