IBM Mainframe Forum

02 01 01 21 7C

That is packed decimal so if you want to convert it to text you will have to unpack it first.

zoom wrote:I tried couple of tools but didn't get much help.

When i open the data file using Hex editor data looks : 02 01 01 21 7C

when i convert this to EBCDIC text , it is <STX><SOH><SOH><SOS>@ . But my target data should be 20101217.

Help should be appreciated.

Are you sure you have everything the right way around? You are saying you have a file in EBCDIC which you want to have in ASCII for to insert into a database. I'm not "up" on such things, but a database on a mainframe wanting ASCII seems odd.

As NicC says, the field you are using in this example is almost certainly a "packed decimal" field. If you want to convert this to "text" (nothing to do with ASCII at all) then just, in some programming language, "move" the field to a "display" type field. This will give you F0 F2 F0 F1 F0 F1 F2 F1 F7 C7 in the Hex editor and 02010121(7). If you don't "see" the final "7", make sure the field is "unsigned".

If you want to load your example into a database, you will have no problem already. On IBM machines, the databases can handle "packed" numbers, which is what you have.

You have EBCDIC. EBCDIC is what IBMs speak. EBCDIC is a code with 256 posibilities. ASCII is a code with 128 possibilities.

If you really have any conversion, I'd expect your incoming file to be in ASCII. Then, as long as no one has done anything stupid (like putting any sort of "non-display" data on it) the operating system will handle the conversion, as long as you tell it the input is ASCII (or, indeed, the output is ASCII). There are two sets of translation tables, one for input, one for output. They are "patchable", but I don't know if you can have one specific for you. Ask your techies...

But, I think you just have a misunderstanding. Your data, on the sample, seems to be in EBCDIC. EBCDIC has visual codes (like letters, numbers, symbols) and everything else is valid, 00 to 256, it is just data.

Why you shouldn't have binary/packed in a file for translation is that the translation tables don't know that it is part of a binary/packed field, and would just convert it if it happend to be the value of a character or symbol. Changing your binary/packed value.

Obviously, nobody bothered to use HEX DATA...

OS ORGANIZADORES DO "CONCURSO
MAINFRAME" GOSTARIAM DE AGRADECER
POR SUA PARTICIPACAO. SEJAM BEM
VINDOS TODOS QUE PARTICIPAM
DO CONCURSO PELA PRIMEIRA VEZ
E AQUELES QUE PARTICIPARAM
EM 2007. ESTE ANO ALGUMAS TAREFAS
NOVAS FORAM INCLUIDAS PARA MELHOR
DESAFIAR A TODOS. DESEJAMOS
BOA SORTE DURANTE TODO O
CONCURSO. FAZEMOS VOTOS QUE
SEJA O MAIS PROVEITOSO POSSIVEL.
"BOA SORTE!"

Apparently it's Portuguese and Google translates it to:

THE ORGANIZERS OF THE "CONTEST
MAINFRAME "WOULD LIKE TO THANK
For their participation. BE WELL
ALL WELCOME TO ATTEND
THE COMPETITION FOR THE FIRST TIME
AND THOSE WHO PARTICIPATED
IN 2007. SOME JOBS THIS YEAR
NEW BEEN ADDED TO BETTER
CHALLENGE TO ALL. WISH
GOOD LUCK FOR ALL
CONTEST. VOWS TO DO
IS as good as possible.
"GOOD LUCK!

prino wrote:Apparently it's Portuguese and Google translates it to:

And this is a good example of how an ASCII to EBCDIC translation would screw up. "Sejam bem vindos" has been translated as though it was "Sejam bem" and "vindos". Other examples in the text, but for human readers we can get the gist (though not, here anyway and usually, the full meaning). For a computer, not so hot. I wonder what happens if you translate the English back to Portuguese? And then the English. I'll give you an English pound if it comes up with the same text, on either leg (and no, I haven't tried it myself).

BillyBoyo wrote:

prino wrote:Apparently it's Portuguese and Google translates it to:

And this is a good example of how an ASCII to EBCDIC translation would screw up. "Sejam bem vindos" has been translated as though it was "Sejam bem" and "vindos". Other examples in the text, but for human readers we can get the gist (though not, here anyway and usually, the full meaning). For a computer, not so hot. I wonder what happens if you translate the English back to Portuguese? And then the English. I'll give you an English pound if it comes up with the same text, on either leg (and no, I haven't tried it myself).

Actually, this has nothing to do with the ASCII-EBCDIC translation, but everything with the fact that Google Translate isn't intelligent enough to discard the CR/LF's added by CUT & PASTE...

I wasn't being serious Especially with the money bit... Have you had a google upgrade? (also I'm not being serious, an unfortunate habit of mine at times).

And if you take them out (I just did it), you get a different translation. In parts better, in parts worse. It is funny

opelosi,

If you want to convert the EBCDIC hex values to (e.g. 'C1' for 'A') to EBCDIC character values, you can use DFSORT's TRAN=UNHEX function, e.g.



The resulting output for your input example would be:



If you want to convert that to ASCII, you could use DFSORT's TRAN=ETOA function.

For complete details on these new functions, see:

http://www.ibm.com/support/docview.wss? ... g3T7000242

Actually, this could be anything. Without knowing how the data was created or where it is coming from .....
It appears to be hex. Hex of ASCII data, hex of EBCDIC, or hex of maschine code? D6 is a hex EBCDIC O, it is also a OC machine instruction, and has no meaning in ASCII.

Guys, look at the dates - the Portugese data was 2008 - we have new data for 2011 which is a packed decimal date (by the looks of it). This is the problem with not starting a new topic. The TreS (Topic reStarter) is probably as confused as a cat in a spin dryer by now.