Generic job to convert ebcdic files to ascii.

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
tbtcust
Premium Member
Premium Member
Posts: 228
Joined: Tue Mar 04, 2008 9:07 am

Generic job to convert ebcdic files to ascii.

Post by tbtcust »

Hello All.

I have dozens of ebcdic files I need to convert to ascii.

I want to write a generic DataStage job(s) that converts any CFF file pass to it to ASCII text file. I need to / want to bring in the files and metadata at runtime.

Is this possible with CFF? Please share any experience you may have had.

Thanks in advance for any help.
eostic
Premium Member
Premium Member
Posts: 3835
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

The main problem you will run into, is when the definition of "EBCDIC file" conflicts with what is really in the data set. Unfortunately, many times you might be given what someone calls an "EBCDIC" file, only to find that it is really a "complete binary" file from the mainframe ----- which means that it is very likely that the data is mixed --- some is character (and likely EBCDIC for those columns), and some might be true binary numeric (integers and decimal columns, and more, usually to represent numbers).

What that means is that you can't easily (if it is indeed mixed) just "convert the whole file"....you need to do it on a more column by column oriented basis, in a follow-up Transformer, after you have successfully parsed all the columns, their occurs clauses, etc.

This topic is more than can be easily discussed in a forum post, but one thing to look at quickly is what the copybook looks like, if it came from COBOL originally. Do you see picture clauses that end in a period, with nothing else? Do you see "character" explicitly stated? A mixed copybook will have things like "COMP-3" everywhere. ...and even "signed" zoned decimal could create some issues for you in a pure EBCDIC to ASCII conversion.

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/07/29/open-igc-is-here/">Open IGC is Here!</a>
eostic
Premium Member
Premium Member
Posts: 3835
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

The main problem you will run into, is when the definition of "EBCDIC file" conflicts with what is really in the data set. Unfortunately, many times you might be given what someone calls an "EBCDIC" file, only to find that it is really a "complete binary" file from the mainframe ----- which means that it is very likely that the data is mixed --- some is character (and likely EBCDIC for those columns), and some might be true binary numeric (integers and decimal columns, and more, usually to represent numbers).

What that means is that you can't easily (if it is indeed mixed) just "convert the whole file"....you need to do it on a more column by column oriented basis, in a follow-up Transformer, after you have successfully parsed all the columns, their occurs clauses, etc.

This topic is more than can be easily discussed in a forum post, but one thing to look at quickly is what the copybook looks like, if it came from COBOL originally. Do you see picture clauses that end in a period, with nothing else? Do you see "character" explicitly stated? A mixed copybook will have things like "COMP-3" everywhere. ...and even "signed" zoned decimal could create some issues for you in a pure EBCDIC to ASCII conversion.

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/07/29/open-igc-is-here/">Open IGC is Here!</a>
vmcburney
Participant
Posts: 3593
Joined: Thu Jan 23, 2003 5:25 pm

Post by vmcburney »

I don't think this is possible because there are usually several manual design steps required to convert an EBCDIC file into a delimited data file. There can be multiple outputs for different record types. I think it is possible to convert a file format an hour manually with someone who has access to the copybooks, longer for complex copy books.

To reiterate what Ernie said:
one thing to look at quickly is what the copybook looks like, if it came from COBOL originally. Do you see picture clauses that end in a period, with nothing else? Do you see "character" explicitly stated? A mixed copybook will have things like "COMP-3" everywhere. ...and even "signed" zoned decimal could create some issues for you in a pure EBCDIC to ASCII conversion.
This really depends on how complex your copybooks are and how accurate they are in describing the EBCDIC file.
Post Reply