problem viewing the output of cff stage

[PhilHibbs]

I don't believe that anything is corrupted here. I get the impression that they just mean an "ascii" versus "binary" ftp transfer which is all about converting line terminators or not, got nothing to do with characterset conversions.

Not correct. ASCII transfer mode is absolutely about converting character sets.

"00A" is a perfectly valid signed overpunch value, and yes the "A" represents a positive 1 so what that should turn into is "001+" or just "001" as you noted. It all comes down to your lack of proper settings in the stage, you need to find the settings that Phil and I have been mentioning and get them set properly for those fields.

But he isn't seeing "00A", he's seeing "{00". The leading hex value C1 which represents "this digit is zero, but the whole number is positive", and is also an "{" character in EBCDIC, has been converted to an ASCII "{" character, so there's a hex value 7B there instead.

*Update*: So, in summary, transfer your file in BINARY mode, then you should be able to interpret the decimal values as "leading overpunched", either directly in the file stage or in a subsequent Column Export. Any text fields will also still be in EBCDIC, so you need to specify that in those column properties.

[anandsh16]

But he isn't seeing "00A", he's seeing "{00". The leading hex value C1 which represents "this digit is zero, but the whole number is positive", and is also an "{" character in EBCDIC, has been converted to an ASCII "{" character, so there's a hex value 7B there instead.

sorry my mistake the actual values are"0000000000000000{" .So the sign is trailing.
Anyway,i have requested Mainframe guys to send an EBCDIC fixed format file.They confirmed earlier that they are currently doing an ASCII conversion before sending the file through C:D gateway.

So,they will be sending an EBCDIC fixed format file . when sending the file through C:D gateway they will send in binary mode.

I think that should solve the issue ..ofcourse keeping the fingers crossed.

Anyway thanks to you all for your all round interest and help !!

[PhilHibbs]

he's seeing "{00". The leading hex value C1 which represents "this digit is zero, but the whole number is positive"...

That's C0, not C1, oops

[chulett]

OK, got the ASCII conversion thing wrong never having done any from a dang mainframe in my life (or any other native EBCDIC source). Sue me.

And I went with the whole "00A" example because that was what was reported (and since recanted, I see) in the post I was responding to. Heck, even the "{00" examples were wrong. And he still will have the problem as he can't seem to find where to specifiy the whole overpunch thing that took us down this road in the first place. I've got zero access to DataStage so perhaps some kind soul could take pity on them and give some detailed instructions on exactly how to set same.

And I still think there's no "corruption" or need to stop the ASCII transfer as these are all display values, not packed, so that's a non-issue in my mind. [sticks out tongue]

[PhilHibbs]

And I still think there's no "corruption" or need to stop the ASCII transfer as these are all display values, not packed, so that's a non-issue in my mind. [sticks out tongue]

It's a non-issue in your mind, because you see '{' and can see that that's a trailing overpunched zero. The computer, however, sees a hex value 7B (ASCII '{'), and that means nothing in the context of a decimal field, it would expect a hex value of C0 (EBCDIC '{') to represent trailing overpunched zero. So, your mind being superior to a computer cannot see the problem. You have to think stupid, and I have leagues of head-start on you on that one .

[chulett]

These are the times when I wish I still had a DataStage gig so I could test crap like this for myself. Ah, well. Still, nothing about this is unsolvable and I'm sure they will get the proper output... eventually.