Put decimal point in right position while parsing data by cobol descriptor

Question

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?

Answer 1

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.

Answer 2

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.