IBM Mainframe Forum

NicC looks at the bigger picture!

I am sure , we are getting EBCDIC file only. the data which i posted in the thread (02 01 01 21 7C ) came from hexa format. This in particular when i open the EBCDIC file using hexaeditor i can see the data like that.

From that i can manually convert and check the data, but it is a huge file which is in gb's so i want to know is there a tool or any code which will convert this IBM ebcdic packed codes to ascii or whatever the readable format. And we are not using IBM DB2 databse, we are using oracle to load all this ebcdic file.

It doesn't matter if your database is DB2 or not. If you are running on an IBM mainframe, your database (whatever it us) naturally "understands" EBCDIC. If you are running on pretty-much anything else, your database (Oracle in this case) "naturally" understands ASCII (most, most, most likely, anyway).

If you can tell us what Operating System you are using, or what machine you are using, we will know whether you need to convert your incoming EBCDIC file to ASCII or not. If you do need to convert it to ASCII (ie you are not running on IBM mainframe) you will then need to find a forum that knows about your operating system to go further.

If you are on an IBM mainframe, then we can offer some advice. What is your skillset? How have you ended up with this task? You have an Oracle database to load the stuff into, what tool do you have to do that?

Assuming your data is 'unpacked' EBCDIC, and you know rexx:

converts the data you have into what we would expect it to be

to BillyBoyo:

We are using Windows environment and we are getting packed ebcdic files from 3rd party. We don't have any access to mainframe environment.

I am a database developer, this is the first time i am playing with ebcdic files.

OK, getting somewhere.

I had three rules for the data when providing files to external sources: 1) Headers and trailers with dates and counts; 2) No non-display (so, to put it another, no non-printable characters - I guess except a space, which I guess counts as "printable" even if you can't see it) fields; 3) file en-coded the way the receiver needs it for their system.

I'm going to guess "none-of-the-above".

If the file on the mainframe is being created for you, it makes enormous sense to get them to fix it. You will otherwise be doing "unneccesary-waste-of-time work". The people creating the file and the people giving you the task haven't fully grasped the requirements, so you end up with stuff that you should just never have to bother about.

If you can't get anywhere, you need to find out if Windows can handle EBCDIC data. I don't just mean if Windows can translate EBCDIC to ASCII, because that will not be good enough for you. Because of the "packed" fields on your data (and, if there are, any binary fields), you need the translation at the field level, a record-level translation can/will corrupt your data.

How are you getting the file onto your system? If some file-transfer package connected to a mainframe, see what the data looks like when you don't ask for the conversion.

Your first step, I think, though, is to go back and try to get the file produced properly. If not, then you have to find some realiable help on the Windows side. Sorry not to have better news.