3

我正在尝试通过 Java 中的 cobol 描述符解析 txt 文件中的数据。当我使用这种方法时出现了问题：

Record net.sf.cb2java.copybook.Copybook.parseData(byte[] arg0).

在 cobol 描述符中，有一行：

20 ACCD-LONG-SECONDS          PIC 99V9999.

在这种情况下，对应的结果应该是小数点左边2位和小数点右边4位。但我得到的是小数点右边的6位数字。例如，如果原始文件中的数据是 123456，我们期望的是 12.3456，但我们得到的是 0.123456

任何人都可以从这里帮助我吗？

4

2 回答 2

3

这是 cobol 处理数据的方式，即使它不显示它知道数量为 12.3456 的昏迷

要显示它，您可以制作（PIC 99.9999 或 Z 用于删除零）：

20 ACCD-LONG-SECONDS          PIC 99V9999.
20 ACCD-LONG-SECONDS-Z        PIC ZZ.ZZZZ.
   .
   .
   .
   MOVE ACCD-LONG-SECONDS TO ACCD-LONG-SECONDS-Z 
   DISPLAY ACCD-LONG-SECONDS-Z

为什么不看看 JRecord？http://jrecord.sourceforge.net/JRecord04.html 或http://www.legsem.com/legstar/

它比 cb2java 更新。

于 2013-08-24T21:10:16.207 回答
3

在我看来，您的接口文件定义不正确。“COBOL”文件只能是文本数据。如果有符号，则应该有一个实际的 +/-，如果有小数位，则应该有一个实际的小数点。或者，对于小数位，“缩放因子”是可能的，并且对于浮点数据的文本表示是必需的。

你有一个“隐含的”小数点。您使用的方法似乎没有正确理解这一点。如果它给你.123456，那么它根本不起作用。如果它不适用于隐含的小数位，它也可能不适用于其他定义。

最安全的方法是切换方法。下一个最安全的方法是修复您正在使用的方法。下一个最安全的是，在收到结果后，自己进一步解析定义以识别隐含小数位的位置，并做一些愚蠢的事情，比如乘以十的正确幂。

请记住，使用最后两个，您可能仍会遇到其他问题。如果 cb2java 处理文本数据但不可靠，为什么继续使用它？

cb2java 的文档是怎么说的？也许那里有什么帮助？系统设计和数据设计和程序规范是怎么说的？

在 COBOL 中，将所有数据生成为“文本”并将所有数据作为“文本”接收并将其转换为 COBOL 系统所需的格式是很简单的。由于糟糕的设计，你不得不做额外的工作。

如果您无法更改文件，我建议您使用 JRecord。即使更改了文件，JRecord 似乎也是一个更好的方法。

是的，您已经完成了代码，但是当设计出现问题时，这些事情就会发生。至少将这些信息反馈到设计过程中，这样它就不会再次发生。

如果你只是为了保存你的代码而修补一些东西，你会得到一些更难以理解和维护的东西，而且更容易出错。

一路走来，概念证明被遗漏了，而你是受苦的人。在不知道它是否有效的情况下，不应该启动文件的代码。我希望你没有多个文件。如果是你做的POC，切换到JRecord应该没有问题，所以我猜不是。

也许您对文档很幸运。除此之外，好处在于改进设计过程和您的经验，这意味着您将来不会犯类似的错误步骤。

于 2013-08-25T00:11:17.737 回答