1

可变长度 QSAM 记录的最大记录长度为 32,760 字节。

我们文件的当前记录长度对我们来说是可以的，但是为了处理更多信息，我们必须扩展这个文件，它的长度将超过 32K ( LRECL> 32760)。

拆分记录对我们来说不是一个好的选择，因为它会影响我们现有的系统。

我不确定SPANNED在此处使用带有 VSAM 的记录是否可以解决此问题。

//DEFINE EXEC PGM=IDCAMS
//SYSPRINT  DD SYSOUT=A
//SYSIN     DD *

  DEFINE CLUSTER (NAME(dsname.K1719) INDEXED VOLUMES(xxxxxx) -
         TRACKS(1) KEYS(17 19) RECORDSIZE(40 110) SPANNED) -
         DATA (NAME(dsname.K1719.DATA)) INDEX (NAME(dsname.K1719.INDEX))
/*
//

这会解决我们的问题吗？

4

2 回答 2

3

如果您使用 Unix 系统服务文件，则不受 LRECL 的 32K 限制。有下游效应。

  • 如果您使用 COBOL 处理文件，您可以在 ORGANIZATION 子句中使用 LINE SEQUENTIAL，但您的 LRECL 限制为 1M。
  • 如果您使用 COBOL 来处理文件，您可以避开 COBOL I/O
    并使用 Cfopen()等来绕过上面提到的 1M LRECL 限制，但是您正在向公认的假设 COBOL 应用程序添加一些陌生的东西。C 对此类文件没有任何问题，我无法与 PL/I 交谈。
  • 并非所有 DFSMS 和第三方实用程序都完全了解 Unix 系统服务文件。
  • 用于 Unix 系统服务文件的 JCL 结构的学习曲线相对较短，但需要一些学习。
  • Unix 系统服务文件的安全性可能会让您的安全管理员感到反感。setfacl您可能会发现自己必须通过和其他新概念设置访问控制列表。
于 2015-08-15T09:57:44.297 回答
1

@cschneid 答案很有趣。

如果不了解有关文件/应用程序的更多信息，很难给出具体答案。以下是可能有用的想法。

你可以：

  • 把字帖分成几个子记录
  • 向密钥添加一个额外的字节

所以而不是拥有

<key><a record>

你将会拥有

<key><sub-key-1><part-1-of-record>
<key><sub-key-2><part-2-of-record>
<key><sub-key-3><part-3-of-record>
 ...

如果您有一个与文件交互的文件驱动程序，您可以从应用程序中隐藏数据存储方式的详细信息。因此，您可以为每个逻辑记录拥有多个物理记录，并且您的应用程序不需要知道它。如果需要，您也可以拥有多个文件

请记住，您可以在不需要存储在文件中的新字帖末尾添加空间。当您需要向文件中添加字段时，这会派上用场 - 可以节省重新编译大量程序

该文件是否包含逻辑上不同的数据（例如销售和订单等），是否每个访问该文件的程序都使用整个记录？？？

如果是这样，您可以在File-Driver-Program的调用中添加一个请求类型：

   Call "FilePgm" using GET-ORDER  Order-Copybook
or 
   Call "FilePgm" using GET-SALES  Sales-Copybook 
or
   Call "FilePgm" using GET-EVERYTHING  Everything-Copybook

拥有多个调用类型/copybook 的优点是，如果 Order-Copybook 发生变化，则不需要重新编译仅使用 Sales-Copybook 的程序，反之亦然。这将使将来更容易更改文件。

最后是数据库选项！！！, 要么

  • 完全重写

  • 或使用二进制blob。这些在二进制 blob 上的限制为 2gb

    使用 DB2，您可以使用很有用的Compression 。大型记录通常具有高压缩比。压缩的好处不是节省空间，而是减少了 IO。

于 2015-08-16T07:34:18.863 回答