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.