views:

555

answers:

3

Hi all,

I'm uploading an ebcdic file(converted from ascii) from Windows OS to Mainframe. My problem is that when I checked the file after uploading it, I see alot of new lines. When I tried to check it with its hex dump I discovered that when mainframe sees a x'15' it translates it into a newline. In the file there are packed decimals so the hex could contain let say a x'001500001c' but when I upload it, mainframe mistook it as a new line. Can anyone help me with this problem?

+1  A: 

You should put your FTP client (or library if the upload is done by your code) into binary (IMAGE TYPE) mode instead of ascii/EBCDIC if you are sending a file already in EBCDIC i believe.

VirtualBlackFox
I'm trying to upload the file in ebcdic type. I tried uploading it in binary or type I but the problem is that it does not contain any new lines anymore. The data set should contain a new line every row but when I upload it using ebcdic type some unnecessary new lines appear.
Grekoz
Your data change while using binary (IMAGE) upload ? Except if your server doesn't support it (It's not mandatory) i don't see how it could hapens.
VirtualBlackFox
When I upload it using ebcdic type the data is fine except for unnecessary new lines or cr/lf. When I upload it using Binary the data does not contain a cr/lf anymore. Well The server does support binary uploads.
Grekoz
I tried uploading using binary and converting the file in ascii and ebcdic. Using ascii conversion the data is unreadable after uploading using binary type, while using ebcdic the data gets to be readable but does not contain cr/lfs.
Grekoz
Are you sure of what your convertion program does is right ?The 0x0D 0x0A sequence in a windows text file should be converted differently if it is a pure binary data in your input (should be translated to 0x0D 0x25) than if it is a new line (0x15)
VirtualBlackFox
(when converting from a windows text file to an EBCDIC one)
VirtualBlackFox
+1  A: 

It depends on the type of target "file" that you're uploading to.

If you're uploading to a member that has fixed block size (e.g., FB80), you'll need to ensure all the lines are padded out with spaces before you transmit it up (in binary mode).

Text mode transfers are not suitable for binary files (and your files are binary if they contain packed decimals - there's no reliable way for FTP to detect real line-end characters).

You'll need to fix your Windows ASCII-to-EBCDIC converter to be able to generate fixed length records.

The only other option is with a REXX script on the mainframe but this would still require being able to tell the difference between a real end-of-line marker and that marker within the binary data.

You could possibly tell the presence of a packed decimal by virtue of the fact that it consisted of BCD nybbles, the last of which is 0xC or 0xD, but that could also cause false positives or negatives.

My advice: when you convert it from ASCII to EBCDIC, pad out the lines to the desired record length at the same time.

The other point I'd like to raise is that if you just want to look at the files on the mainframe (not use them from any code that requires EBCDIC), the ISPF editor includes a few new commands (as of z/OS 1.9 if I remember correctly).

SOURCE ASCII will display the data as ASCII rather than EBCDIC. In addition, the LF command allows you to massage the ASCII stream in an FB member to correctly fix up line endings.

paxdiablo
A: 

Hi Pax and VirtualBlackFox,

I got it right now. I tried uploading the file using Binary Type. The total length of the dataset should have been 2747 but what I was uploading was 2749 that is why when I uploaded it in mainframe using Binary the placing didn't seem right. Thanks for all the support. Thanks Pax and VirtualBlackFox.

Grekoz