As a java developer I'm new to mainframes and the use of jrecord.
I have been given a cobol file that I need to parse with a given copybook. In general it is working great however I am having problems with numeric fields.
I know that the first 4 characters of the file I need to parse should hold the number 48 in binary format. When I read in the file, before parsing against the copybook, I see the first four bytes as 0,0,0,48. I declare the field in the copybook as
PICTURE S9(4)
(I have also tried variants of COMP)
When I parse it against the copybook, using jrecord, I get a value of zero.
It's the same when I write out my own file. The documents I have say that I need a length field that is a 4 byte binary field however when I to write the copybook format I don't get 0,0,0,48 written to the file.
Hi,
As a java developer I'm new to mainframes and the use of jrecord.
I have been given a cobol file that I need to parse with a given copybook. In general it is working great however I am having problems with numeric fields.
I know that the first 4 characters of the file I need to parse should hold the number 48 in binary format. When I read in the file, before parsing against the copybook, I see the first four bytes as 0,0,0,48. I declare the field in the copybook as
PICTURE S9(4)
(I have also tried variants of COMP)
When I parse it against the copybook, using jrecord, I get a value of zero.
It's the same when I write out my own file. The documents I have say that I need a length field that is a 4 byte binary field however when I to write the copybook format I don't get 0,0,0,48 written to the file.
For the writing part I thought I would try
then
recird.getFieldValue(...).set(arr) ;
However that seem to fall over complaining about it wanting a number.
Any thoughts?
Thanks in advance.
Last edit: richard bradwell 2015-11-08
sounds like you have a packed decimal (e.g.
S9(6) COMP-3
) in little endian format (FMT_INTEL
)E.g
data (hex values)
Output:
Does that clarify?
Last edit: Brian Reynolds 2015-11-08
Try
in cobol you are specifing the number of decimal digits and not the number of bytes. The comp gives you big-endian binary integer. so
The alternative is to use the RecordEditor Xml file schema: