在通過cobol描述符解析數據時將小數點放在正確的位置

我想通過java中的cobol描述符解析txt文件中的數據。也有一些是錯誤的，當我用這個方法：在通過cobol描述符解析數據時將小數點放在正確的位置

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

在COBOL語言描述，有一行：

20 ACCD-LONG-SECONDS   PIC 99V9999.

在這種情況下，相應的結果應該是小數點左邊2個位數小數點右側有4位數字。但我得到的是小數點右側的6位數字。例如，如果原始文件中的數據是123456，我們所期望的是12.3456，但是，我們得到的是0.123456

任何人都可以幫我從這裏出去嗎？

來源

2013-08-24 WangMango

在我看來，你的界面文件定義不正確。「COBOL」文件只能是文本數據。如果有符號，應該有一個實際的+/-，如果帶有小數位，則爲實際的小數點。或者，對於小數位，「縮放因子」是可能的，並且對於浮點數據的文本表示是必需的。

您有一個「隱含的」小數點。看來你使用的方法不能正確理解這一點。如果它給你.123456，那麼它根本不起作用。如果它不適用於隱含的小數位，它可能不適用於其他定義。

最安全的是切換方法。其次最安全的是修復您正在使用的方法。接下來最安全的是，在收到結果後，自己進一步解析定義，以確定隱含的小數位的位置，並做一些愚蠢的事情，比如乘以十的正確冪。

請記住，在這最後兩個，你可能仍然會遇到其他問題。如果cb2java使用文本數據但不可靠，否則爲什麼繼續使用它？

cb2java的文檔說的是什麼？也許這有幫助嗎？系統設計和數據設計和程序規範說了什麼？

在COBOL是微不足道的產生所有的數據爲「文本」，並接收所有數據爲「文本」，並把它變成了格式要求的COBOL系統。通過糟糕的設計，你一直在做額外的工作。

如果你不能得到的文件改變了，我建議的JRecord。即使文件已更改，JRecord似乎也是更好的選擇。

是的，你已經得到了你完成的代碼，但在設計的時候是有過錯的，這些事情發生。至少將這些信息反饋給設計過程，以免再次發生。

如果你只是爲了保存你的代碼而修補某些東西，你會遇到一些更難以理解和維護的東西，哪些更容易出錯。

沿途的某個地方沒有一個概念驗證，而你是受過損害的人。沒有知道它的工作原理，文件的代碼不應該已經啓動。我希望你沒有多個文件。如果是你正在做的POC，切換到JRecord應該沒有問題，所以我猜測它不是。

也許你會對文檔感到幸運。除此之外，它的好處在於改進了設計過程和您的經驗，這意味着您將來不會再犯類似的錯誤操作。

來源

2013-08-25 00:11:17

我的過程是通過ASCII將txt文件轉換爲字節。然後，我可以使用parseData（byte [] arg0）通過佈局文件將它們解析爲適當的結構。到現在爲止，它只是不能用小數點。我會嘗試JRecord。謝謝你的建議人。 – WangMango

據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-24 21:10:16 MrSimpleMind

對不起，我可能解釋不好。結果是0.123456。我用java通過cobol描述符來解析txt文件中的數據。 – WangMango

我會看看它。但是，我的問題仍然可以解決而不改變方法？ – WangMango

JRecord將正確處理s9（？）V9（？）/ 9（？）V9（？）。基本上V表示假定的小數位（文件中不存在小數點）。 –

在通過cobol描述符解析數據時將小數點放在正確的位置

回答

相關問題