Need Help on PS Organization and FB record format

[Govindu Narendr]

Hi Bruce Martin,
Have a PS organization binary file with FB record format but when we use with attached code we are getting junk character.PLease find attached Jrecord code,Copy book and data file.Please help.
and below is the file information.
Organization . . . : PS
Record format . . . : FB
Record length . . . : 8036
Block size . . . . : 24108

[Bruce Martin]

The problem is the copybook is 8000 bytes long while the RecordLength is 8036.
The IOBuilder is using the copybook-length as the Record-Length.

Possible Solutions:

• add a Filler pic x(36) to the end of the copybook.
• Use low level routines to read exactly 8036 bytes. See attached file

[Govindu Narendr]

Hi Bruce Martin,
Sorry for the late reply and I ued attached program without adding Filler it works successfully. Thank you somuch for your help.

[Bruce Martin]

no worries

I have got the Template that generated the Getter/Setter-Wrapper / Pojo working.
I am not ready to do a full release yet but I can put out an "upgrade" if it is of use ???

[Mukul Jain]

Hello Bruce

I am a COBOL developer with basic knowledge of java. I am trying to convert a sample LINE SEQUENTIAL/SEQUENTIAL file generated by a COBOL program(JRECMOD.cbl). The issue is as follows:

Datafile generated from JRECMOD.cbl:    OUTDATA (expected output)
After I run data2xml conversion:        OUT.xml (expected output)

After I run xml2data conversion on OUT.xml: OUTDATA_conv (not same as OUTDATA)

I am expecting the unconverted(OUTDATA) and converted(OUTDATA_conv) data files to match. However, I see that there is a difference of one character. Again, if i run data2xml on OUTDATA_conv, I get a perfect XML output. I am not able to comprehend this behaviour.

cobxml.sh is the script I have written for the testing.

CPYBOOK.cbl is the layout copybook.

Could you please let me know if this behaviour is expected. If not, could you point out what is it that I am doing incorrectly?

Using GNU Cobol v2.0 on RHEL

All files referred to in the message are attached

Thank you

[Bruce Martin]

The difference is on the Zoned signed numeric field (pic s99). I have used the same code as
for Fujitsu Cobol (or GNU-Cobol might of been changed).

Basically GNU-Cobol is writing 99, while JRecord is using the overtype (+ve) version 9I

I will

• update JRecord for this issue
• You migh find GNUCobol accepts 9I (not sure).

Also I would advise against using Line-Sequential with binary files as you can get \n
in a binary field and JRecord will treat that as EOL

---

Looks like I need to setup GNU Cobol and retest - I have not done that for a long time

[Mukul Jain]

Thank you Bruce for your prompt response. Do let me know when you update JRecord for this issue.

[Bruce Martin]

Attached is an updated JRecord.jar for a fix for GnuCobol.

There are other changes related to CodeGen and should not affect you.

I will update the Source in subversion for the Changes; Not sure when I will do an official release;
Will complete other changes and try and retest GNU Cobol

[Mukul Jain]

Working perfectly - thank you!

I shall wait for the official release.

[Bruce Martin]

I have released CobolToXml as a separate project. In version 0.98 of the RecordEditor you can enter Cobol/Data File deails on GUI screen and generate CobolToCsv batch scripts. See

• http://coboltoxml.sourceforge.net/wCbl2X05.htm

Updates to JRecord should occur next week