Page 1 of 1
EBCDIC to ASCII and back
Posted: Tue Mar 29, 2005 5:04 pm
by santosh
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
Posted: Tue Mar 29, 2005 6:35 pm
by chucksmith
Have you looked at the Complex Flat File stage?
Posted: Wed Mar 30, 2005 1:50 am
by ray.wurlod
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)?
EBCDIC to ASCII and back
Posted: Wed Mar 30, 2005 2:44 am
by santosh
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.
Posted: Thu Mar 31, 2005 4:09 am
by DSguru2B
You can do it in the transform stage itself. ie; convert it from EBCIDI to ASCII.
Posted: Thu Mar 31, 2005 8:59 am
by ds_developer
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
Posted: Thu Mar 31, 2005 9:05 am
by mkeevil
We currently do that in the transform stage, the code looks something like this:
Trim(DataTypeEbcdicToAscii(Recovery1ODBC.DataLine[60,1]))
Posted: Thu Mar 31, 2005 2:07 pm
by mhester
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.