Question

我试图通过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

有人可以帮助我吗？

Answer 1

这是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更新。

Answer 2

我认为您的界面文件定义不正确。 “COBOL”文件应仅为文本数据。如果签名，则应该有一个实际的+/-，如果有小数位，则为实际小数点。或者对于小数位，“缩放因子”是可能的，并且对于浮点数据的文本表示是必要的。

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

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

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

cb2java的文档说什么？也许有一些东西有帮助吗？系统设计和数据设计和程序规范说了什么？

在COBOL中，将所有数据生成为“文本”并将所有数据作为“文本”接收并将其转换为COBOL系统的格式要求是微不足道的。通过糟糕的设计，你一直在做额外的工作。

如果您无法更改文件，我建议使用JRecord。即使文件发生了变化，JRecord似乎也是一种更好的方式。

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

如果你为了保存你的代码而进行补丁，那么你将会遇到更难理解和维护的问题，而且更容易出错。

错过概念验证的某个地方，你就是那个遭受苦难的人。如果知道它的工作原理，就不应该启动文件的代码。我希望你没有多个文件。如果它是您正在进行的POC，切换到JRecord应该没有问题，所以我猜它不是。

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

在通过cobol描述符解析数据时，将小数点放在正确的位置

2 个答案: