Dear Forum,
I am currently having a problem where the exclamation mark (!) is being displayed as a U with an umlaut on it after I retrieve it on the mainframe and display it on a Windows platform. I know there are multiple translation tables, but could somebody point me in the right direction as to which table it could be and where in the parameters do we make the change. I know there is a parmeter in the Nat Config file and the Broker Attribute file.

Where should I start looking first. Could someone point me to the documentation, I have tried but could not find the detail.

Should this not be a universal translation table (ebcdic to ascii Unicode)?

Thanks
Hennie

From the Documentation Overview
→ Administration
→ Administration under your-OS
→ Configuring Broker for Internationalization

Sorry that I can’t be of more help, but I’ve not seen this under EntireX.

On a related note, I have seen this when loading mainframe data to Adabas on Windows. We were getting the same “U-umlaut” character instead of a backslash, so we added the ADATRT parameter to our compress step to translate the character properly (h’E0’ → h’5C’).

Are you using ACI or RPC calls?

If you are using ACI, there is an assembler user exit example USRTCHA for Broker that can be adapted to your site requirements and then requested for any services that need it. This is a lower overhead approach than the internationalization options.

The service needing the custom translation should add TRANSLATION=USRTCHA (or whatever the translation exit is called).

http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuite8_fcs/EntireX/adminZos/internatBroker.htm#writeTranslationUserExits

The problem is that “EBCDIC” is not really a single encoding; it’s a family of related codes. Once you go beyond decimal digits, the Latin characters used by English, and a handful of basic punctuation marks there really is no standard EBCDIC interpretation for code points. In particular, you have been able to buy the same 3270-class terminal model from IBM and get different interpretations depending on which country you ordered it from.

The SAGTCHA routine that Software AG ships as the default with Broker uses the version of EBCDIC that IBM used in Germany and Austria. (Surprise!) If you’re somewhere else, you should follow Douglas Kelly’s advice and use the sample USRTCHA code that came with broker to write your own custom translation routine. I’ve written three!

I’d like to make some Notes here on this discussion because there are several wrong issues here:

1. “If you are using ACI, there is an assembler user exit example USRTCHA”. This is not correct. See the tables in “What is the Best Internationalization Approach to Use?” for Conversion approaches to RPC and ACI:

• Internationalization for ACI-based Programming
• Internationalization for RPC-based Components and Reliable RPC
  a simple rule is (all approaches can be used for RPC, and all except SAGTRPC for RPC)

2. it is really no need to write anymore a translation table with EntireX. Using the TRANSLATION User Exit has many limitations, see
   Introduction to Internationalization and go to Translation User Exit.

For Windows EntireX does (mostly) not required any codepage to be configured. For mainframe it must be configured. You should find out the
ebcdic code page number (or alias of it) and define it e.g.

• as broker ebcdic default code page, see “Codepage-specific Attributes” in broker attribute file “DEFAULT_EBCDIC_IBM”
• with your EntireX component on the mainframe. This overwrites the default broker code page.

I want to correct what i wrote yesterday. The translation User EXIT can be used for ACI (as well as for RPC) but i would not recommend to use it. The USER Exit approach is from the early Broker and EntireX days (more than 15 years ago and is not state of the art anymore - but could be stilled used). It has many limitations, see docu link in yesterday post.

I would recommend to use ICU Conversion. If you do not have any multibyte codepages the communcation type ACI or RPC is irrelevant either. Otherwise if you have multibyte codepages it gets more complicate. Please note also UTF8 is multibyte.

So if you have single-byte codepages only, you should proceed as follows:

For Windows EntireX does (mostly) not required any codepage to be configured. For mainframe it must be configured. You should find out the
ebcdic code page number (or alias of it) and define it e.g.

• as broker ebcdic default code page, see “Codepage-specific Attributes” in broker attribute file “DEFAULT_EBCDIC_IBM”
• with your EntireX component on the mainframe. This overwrites the default broker code page.
  In the broker CONVERSION=SAGTCHA must be defined for the service (ACI opr RPC)

Regards Bernhard

The problem I encountered in using ICU conversion was simply the overhead - it was more CPU and something like 100mb of memory just to turn it on.

The user exit does not provide all of the functionality of code page conversions, but for environments that don’t need that level of conversion yet, the user exit is fast and simple.

Of course, the environments that don’t need more advanced conversion are becoming fewer and fewer as time goes on and the need to accomodate more language sets becomes prevalent, even in the US.

The old TRANSLATION exit is faster then CONVERSION but has several restrictions. In short it can be used for both ACI and RPC if the following applies:

• only single-byte code pages are used
• all EBCDIC-based client or server applications use the same code page
• all ASCII-based client or server applications use the same code page