Trying to read in a monster sized file created on z/os.
Using its copybook with opencobol 1.1 on SUN10 (sparc)....

the COMP-3 fields are not being groked by opencobol...

Had a MF buddy create me a file thats pic 9(15) COMP-3 with the value: 000001234567890

od in hex shows it as this:
0000 0183 a4b7 690f

but it is non-sensical to opencobol...

wrote an OC program to write pic 9(15) comp-3. writing the same value and it looks ok in hex:
0000 0123 4567 890f

So did my NDM mess datafile up, or do I have ebcdic or endian issues?

thx for your help.
JurgyMan

Hi,

when I convert

01 23 45 67 89 0F

from ASCII to EBCDIC the result is

01 83 A4 B7 69 0f

so your guess with EBCDIC<->ASCII was right .

Maybe you have converted it "to often" or not -> but I think you should not convert your file.

It is not "good" to convert Files with packed Field between ASCII/EBCDIC - if possible try to read it "unconverted" in OC you can set for example the "BS2000" flag to read/write files in the ebcdic format. Have a look at the doc for more flags/options to set EBCDIC/ASCII file format.

The "normal" converter does not know anything about "comp" fields - so a comp field with "45" is a big "E" (ASCII) for the converter -> a big "E" is C5 in EBCDIC. I hope this short example explains why it is not good to convert files containing binary/comp filed between ASCII/EBCDIC.




Gandalf

PS Another "solution": Do not use packed fields in files that are transfered between systems with different encodings
PPS Do not forget that a lot of FTP Tools will convert the files automaticly when you select "Text" files - use the binary option to transfer them without changing it

Thanks so much for the detailed, thoughtful response.

What threw me is the file has readable TEXT within it...
Is EBCDIC printable chars [A-z] the same as ASCII?

So yes the COMP3 data is packed and still ebcdic...

When you say check to doc, do you mean the FAQ?
Because thats the only substantive doc I find on opencobol...

There BS2000 is only mentioned as a flag: -std=BS2000 to allow that dialect... doesnt appear to enforce EBCDIC.

I'm trying to use the example code in faq RE: EBCDIC

SPECIAL-NAMES.
ALPHABET ALPHA IS NATIVE.
ALPHABET BETA IS EBCDIC.
PROCEDURE DIVISION.
INSPECT variable CONVERTING ALPHA TO BETA

But get these errors compiling:
Error: syntax error, unexpected ALPHABET, expecting "end of file"
Error: syntax error, unexpected "SPECIAL-NAMES", expecting "end of file"

any assistance greatly appreciated.
Its been about 16 years since I coded COBOL...
Where can I find definitive OpenCobol doc/reference,
and for COBOL in general reference doc?

JM

No, the Characters A-Z,a-z have a different hex value. So when you convert a file between ASCII/EBCDIC the "printable" Characters are converted quiet corret (the "text" is readable in the other character set). But your problem is that a packed field could by representing a A-Z,a-z Character -> so it is converted (and there could also a problem with diffrent EBCDIC encodings - but i've never had any problem with this).

I'm sorry to say so, but by mentioning the "EBCDIC Flag" I got mixed up/confused with MF-Cobol.NET and the OpenCobol compiler.

I will have a closer look at the documentation of the OC Compiler if there is a chance to use EBCDIC Files. But if there is a chance - your Files should be not "readable" on your OC-System. What I mean is, there should be not readable "Text" when you open it with a standard editor with no ebcdic/ascii support.

But I have also a question:
Z/OS = EBCDIC??? Never heard about that?

EDIT:
As far as i understand the oc doc - there is a support of EBCDIC fields/characters. But the FileHandler might not be able to read the file if it is a ebdcid-isam file on a ascii system (without or qith convertig it to ascci). Please correct me if i am not right. It might even occur that the filehandler is not able to read an ebcdic LineSequential File on an ASCII System when it is not converted, because of the different indicators of the LineEnd/NextLine.

As Far as i remember now MF-Cobol filehandler was able to do so, but with quiet a lot of limitations -> so i wrote my own ebcdic file-reader/writer with the CBL_READ/CBL_WRITE funtions. But i am not able/allowed to post this source code here .

OK after figuring out howto force NDM to transfer file asis (ebcdic), I am having success looking at my comp-3 values!

And I can use the:
inspect ALPHANUMVAR converting beta to alpha
trick to handle the ebcdic text fields.

EXCEPT, I'm seeing inconsistent results decoding the packed decimal field.... like if its got trailing zeros, they disappear (decimal place introduced somewhere??)

So i think i'll have to insist on no COMP-3 from SOR.
Thanks for your help
JM

If you have a "say" in how the filres are created on the mainframe, then the best thing to ask fo is that ALL numeric fields be defined as
Usage Display Sign is Leadeing Separate

If you then dcwnload those files (with EBCDIC -> ASCII conversion) bot the numeric and non-numeric fields will be readable.

If your file inlcudes any COMP-??? fields (Binary, Packed-Decimal, or floating-point) then you will have conversion problems.

Other COBOL products (such as IBM's and Micro Focus') have tools to "convert" files intellegently (i.e. change text fields but not packed/binary fields) but no such "generic" tool exists - that OC could use.

NOTE WELL:
Floaging Point (COMP-1 and COMP-2) fields are unusual on z/OS - but if you have any of thsee, then you will have a mor significant migration problem - as the IBM format is totally incompatible with any "norml" PC or Linux/Unix format.

1) If you need to check a mainframe Cobol file, you could look at http://record-editor.sourceforge.net/; There are some basic notes on using with Mainframe-Cobol here http://record-editor.sourceforge.net/MainframeNotes.html

2) I could write a basic Smart Mainframe Cobol to Ascii Cobol conversion Utility (and leave Comp / comp-3 Cobol fields untouched) fairly easily (in Java - a couple of days work). I already have the all the access / conversion code. It will just be a matter of linking it together. The utility will be about 400kb

The limitations on the utility I envision are:

* No Comp-1 / Comp-2 Support
* No Occurs Depending on
* Single Record only
* Result of Redefines will be unpredictable

If any one is interested in the Conversion Utility, let me know / respond here