EBCDIC to ASCII and back

santosh · Post by **santosh** » Tue Mar 29, 2005 5:04 pm

PROBLEM:
We have to develop job which will read Source EBCDIC files as per COBOL copybook layout, do transformations on some fields and then create an output EBCDIC file. We are using DataStage on UNIX to do this.

MANDATORY CRITERIA:
We will be getting EBCDIC files from source and have to push target EBCDIC files to target.

OUR SOLUTION:
We are planning to read EBCDIC files using sequential file stage in datasets, apply transformations on required columns and create target EBCDIC files.

SUGGESTIONS:
Requesting suggestions on possible different architecture to achive my objective.

Regards,
Santosh

chucksmith · Post by **chucksmith** » Tue Mar 29, 2005 6:35 pm

Have you looked at the Complex Flat File stage?

ray.wurlod · Post by **ray.wurlod** » Wed Mar 30, 2005 1:50 am

Do you want to do this using a parallel job (you specified parallel as the job type) or a server job (you posted on the server job forum)?

santosh · Post by **santosh** » Wed Mar 30, 2005 2:44 am

thanks for your reply.
I tried to do this with complex flat file stage but I was unable to change the format according to different record types. I posted the query in server as sequential and parallel file stage is present in both edition.

Wanted to know if the architecture we are using is fine for converting data from EBCDIC to UNICODE in datastage and back to EBCDIC. I believe datastage coverts it to UNICODE while reading.

DSguru2B · Post by **DSguru2B** » Thu Mar 31, 2005 4:09 am

You can do it in the transform stage itself. ie; convert it from EBCIDI to ASCII.

ds_developer · Post by **ds_developer** » Thu Mar 31, 2005 8:59 am

The CFF stage works as a source stage, but not a target. I am writing EBCDIC files in copybook format using the sequential file stage. It is not easy to handle 'depending on' clauses. I ended up using a static layout. DataStage does not have a routine to convert an ASCII number to COMP3. If you have long numbers (like a credit card account number) watch for conversion issues for ASCII numbers longer than 15.
Hope this helps,
John

mkeevil · Post by **mkeevil** » Thu Mar 31, 2005 9:05 am

We currently do that in the transform stage, the code looks something like this:

Trim(DataTypeEbcdicToAscii(Recovery1ODBC.DataLine[60,1]))

mhester · Post by **mhester** » Thu Mar 31, 2005 2:07 pm

Another possible solution might be to push this logic back to the source system by requesting that these transformations be applied at the source via a COBOL program. This could work if

A) the resources exist to do the work
B) the logic is not dependant on anything external to source system

Just a thought and a method I have used with a few customers who had mainframe data and requirements similar to yours.