3

I am trying to parsing data from txt file by cobol descriptor in java. There is something wrong when I use this method: 

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

In cobol descriptor, there is a line: 

20 ACCD-LONG-SECONDS          PIC 99V9999.

In this case, the corresponding result should be 2 digits on the left of decimal point and 4 digits on the right of decimal point. But what I got is 6 digits on the right of decimal point. For example, if the data in original file is 123456, what we expected is 12.3456, however, what we got is 0.123456

Could anyone help me out from here?

WangMango
  • 35
  • 5

2 Answers2

3

It is the way cobol handles data, even though it does not display the coma it knows the amount is 12.3456

To display it you can make (a PIC 99.9999 or a Z for removing the zeros):

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

Why not take a look at JRecord? http://jrecord.sourceforge.net/JRecord04.html or http://www.legsem.com/legstar/

It is more updated than cb2java.

MrSimpleMind
  • 6,334
  • 2
  • 33
  • 42
  • Sorry, I might not explain it well. The result is 0.123456. I used java to parse the data from txt file by cobol descriptor. – WangMango Aug 24 '13 at 21:33
  • I will take a look at it. But could my problem still be solved without changing method? – WangMango Aug 24 '13 at 21:40
  • 1
    JRecord will handle s9(?)V9(?) / 9(?)V9(?) correctly. Essentially V means assumed decimal place (no decimal point is stored in the file). – Bruce Martin Aug 24 '13 at 23:12
  • No decimal point is stored, that is right. But isn't it supposed to add decimal point after parsing by layout file? – WangMango Aug 26 '13 at 20:49
  • 1
    Yes Cb2java, should add the decimal in. The developer stopped after Cb2Java did what he needed. Not sure which version of cb2java you are using (sourceforge or GitHub), the Git hub version (https://github.com/devstopfix/cb2java) has some fixes in it. – Bruce Martin Aug 27 '13 at 08:11
3

To my mind your interface file is defined incorrectly. The "COBOL" file should be text data only. If signed, there should be an actual +/-, if with decimal places, an actual decimal point. Alternatively for the decimal places is "scaling factor" is possible, and necessary for text representation of floating-point data.

You have an "implied" decimal point. It seems that the method you are using is not understanding this correctly. If it is giving you .123456, then it simply isn't working. If it isn't working for an implied decimal place, it may also not be working for other definitions.

Safest would be to switch methods. Next safest is to fix the method you are using. Next safest is to, on receipt of the result, to parse the definition further yourself to identify the location of the implied decimal place and do something silly like multiply by the correct power of ten.

Bear in mind that with these last two, you may still encounter other problems. If the cb2java works with text data but not reliably otherwise, why continue to use it?

What does the documentation of cb2java say? Perhaps there is something that helps there? What does the System Design and Data Design and Program Specification say?

In COBOL it is trivial to produce all the data as "text" and to receive all the data as "text" and turn it into the format require for the COBOL system. Through poor design you've been left doing extra work.

If you can't get the file changed, I'd suggest the JRecord. Even with the file changed, the JRecord just seems a better way to go.

Yes, you've already got your completed code, but these things happen when the design is at fault. At least feed that information back into the design process so it doesn't happen again.

If you patch things up just to save your code, you'll have something which is more difficult to understand and maintain, and which is more prone to error.

Somewhere along the way a Proof Of Concept was missed, and you're the one who has suffered. Without knowing that it works, the code for a file should not have been started. I hope you don't have multiple files. If it is the POC that you are doing, there should be no problem in switching to JRecord, so I'm guessing it is not.

Maybe you get lucky with the documentation. Other than that, the benefits are in improvement of the design process and your experience with this meaning that you don't make similar mis-steps in the future.

Bill Woodger
  • 12,702
  • 4
  • 35
  • 43
  • 1
    My process is turning txt file to bytes by ASCII. Then, I can use the parseData(byte[] arg0) to parse them into appropriate structure by layout file. Until now, it just simply doesn't work with decimal point. I will try JRecord. Thanks for your advice man. – WangMango Aug 26 '13 at 21:27