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
EBCDIC to ASCII and back
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 385
- Joined: Wed Jun 16, 2004 12:43 pm
- Location: Virginia, USA
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
EBCDIC to ASCII and back
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.
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.
-
- Premium Member
- Posts: 224
- Joined: Tue Sep 24, 2002 7:32 am
- Location: Denver, CO USA
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
Hope this helps,
John
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.
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.
Mike Hester
mhester@petra-ps.com
mhester@petra-ps.com