Mainframe, MVS and zOS Discussion

Hi,

One of our other teams where I'm not directly involved has got a problem with the "@" character using in then email-IDs.

I might get murky in my explanation however please bear with me and I'll to add on as and when required.

Three things involved in the problem - mainframe, Rumba emulator and Database DB2. DB2 has got interface with green screen and Web (Java) as well. DB2 resides on mainframe and is a centralized database, that is this data can be fetched from many geographical locations. When data is entered using the web-interface and an email is entered with "@" and fetched back in ENEA region it comes out as "§" (section sign) which is not acceptable, obviously.

I understand that this can be worked upon by the correct code pages but what to if the data is being fetched from a centralized database?

I'm pretty sure the "@" sign is EBCDIC code-page invariant, so it should have been stored as "@" in DB2! And it's 0x40 in both ASCII and UTF-8, so there are also no conversion problems!

Check the Rumba codepage for the ENEA region?

Thanks prino.

Sorry it's EMEA.

In Germany, the point of entry in Rumba, code page is CP273, which encodes the @ symbol in the email address as X’B5’ (and the § “section sign” as X’7C’). So to answer your question for EMEA it's CP273.

On further investigation, I came to know that - "as a general rule of thumb, for green screens, if the locale that authors the data also retrieves it there is no issue. But as data is shared across geographic locales within the team can create issues. And data that moves across platforms may create issues as well because of translations to ASCII encoding as well as UNICODE."

I'm somewhat not convinced with this argument as I've worked with multi geographical locations in other companies too and never observed such a problem. May be there is more to it.

I suspect something is not using the correct code page. EBCDIC 037 has X'B5' as the section symbol and X'7C' as the @ sign. EBCDIC 273 has X'B5' as the @ sign and X'7C' as the section symbol.

Looks like that's the reason but how do I identify that? That's the question.

prino wrote: ↑Mon Jan 22, 2018 9:24 pmCheck the Rumba codepage for the ENEA region?

I think they are using 037, still have a confirm though.

If the data is stored in DB2, will it not just show exactly the way it has been stored. So that means sign "§" was stored incorrectly itself.