EBCDIC and ASCII

abhijit.nayak01 · Posted: Fri Jun 24, 2022 3:40 pm

Hi,
I am having trouble converting between ascii to ebcdic and vice versa.
Frontend team converts the ascii 47EAACED1948CABF to ebcdic x'c752b05519c872ab' and sends the ebcdic/hex value to mainframe. And in mainframe I need to convert it back to actual ascii value but I don't get the desired result. In one scenario I got the desired result but in the below scenario i didn't. Please assist.

abhijit.nayak01 · Posted: Fri Jun 24, 2022 4:43 pm

this one coming correctly as expected

Robert Sample · Posted: Sat Jun 25, 2022 1:04 am

Your first problem is that EBCDIC does not have "a" collating sequence. There are multiple versions of EBCDIC, and characters are not all the same in every version. For example, the square brackets [] can be X'BA' and X'BB' or X'AD' and X'BD' depending upon the version of EBCDIC. I've seen both pairs of characters being used on the same mainframe at different points, so it is not a matter of saying what is right and what is wrong -- both are right in some circumstances.

You need to find out code page is being used in the ASCII-to-EBCDIC translation and use that same code page with what you're doing. This won't necessarily resolve all your problems but it should get you close.

abhijit.nayak01 · Posted: Tue Jun 28, 2022 11:30 am

Thanks Robert.
I have asked the team to find what code page they are using.
Meanwhile I got an solution to convert this
Say for example I want to convert the x'c7'

Then first find the decimal value of x'c7' which is 199.
Then there is a ebcdic to ascii conversion file given 199 decimal value becomes decimal 71 according to that conversion file.

Then convert the decimal 71 to hexadecimal value which is 47.
So, 47 is the ascii value.

Robert Sample · Posted: Tue Jun 28, 2022 6:24 pm

X'C7' in EBCDIC is an upper case G. If your conversion process does not give you an ASCII upper case G, then either you're doing the process wrong or you're using the wrong process.

X'71' in ASCII is an upper case G. So your conversion of 71 to hex 47 is the wrong part of the process -- the 71 is ALREADY in hex.

abhijit.nayak01 · Posted: Wed Jun 29, 2022 11:21 am

Hi Rob,
I think we are on same page.
Front end got x'47' and converted to x'c7' and sent to mainframe.
Mainframe need to convert the x'c7' to x'47' and send it to another system.
how x'47' converted to x'c7'
x'47' numeric/decimal value is 071.
071 ascii to ebcdic numeric is 199 ( conversion table from frontend)
199 hex value is x'c7'
how x'c7' converted to x'47'
x'c7' numeric/decimal value is 199
199 ascii numeric to ebcdic numeric is 071( conversion table from frontend)
071 converted to hex is x'47' (enter 071 as dec in calculator programmer mode will get hex value as 47)
This value comes perfectly using national and display function in my first post. You are correct regarding the value of "G".

sergeyken · Posted: Wed Jun 29, 2022 4:41 pm

There is no need to involve decimal conversion anywhere in this process of translation.

It only increases the whole mess up to 2 or more times higher; there are no other "benefits".

abhijit.nayak01 · Posted: Fri Jul 01, 2022 10:28 am

Thanks for your suggestion. Created a table below
'0101'.
'0202'.
'0303'.
'049C'.
'0509'.
'0686'.
'077F'.
'0897'.
'098D'.
'0A8E'.
'0B0B'.
.
.
occurs 256 times
ebc-key pic x(02)
asc-key pic x(02)

So, like you suggested no more complexity of too many conversion