Highlighted
Absent Member.
Absent Member.
1519 views

[archive] Unicode Options with Acu4GL eXtend products

[Migrated content. Thread originally posted on 28 September 2009]

Hi All,

One of our main achilles heel is the lack of Unicode support in the 4GL product range when reading and writing multi-lingual data on a single English server. This post is to see if anyone has devised a solution to read and write multiple languages using the Acu4GL product range from a single server. It would also be great to hear if you have tried anything even if you decided it was not a functional/possible solution in the end e.g. translation tables, conversion routines etc.

Our Environment:
-We have multiple call centres globally accessing the same Application and database
-These call centres can enter data in varied languages e.g Japanese, Hebrew, German, French, English etc
-A single call centre can also take calls from multiple regions and hence enter multiple languages within the one application interface

What we are trying to achieve:
-Maintain the core application as the main processing tool reading/writing to a database using Acu4GL extend products
-Create a new interface for a part of our application in .NET (or the like) that can be distributed to a wider global audience without the need for client files/registration on the local workstation
-Have a single application server (in English) that can perform all the Acu4GL read/write requests from both the local Core Application and the .NET UI
-All writing/reading by the Core Application and .NET UI is to be done via cobol using the Acu4GL extend product range to maintain existing acucobol business logic and code
-Read and write multi-lingual characters the .NET UI

What we have tried:
-We have experimented with many interoperability options as per Acucorp doco
-Wrunnet.dll appears to be the best fit for our requirements (although not locked in). It requires minimal coding on the asp.net net side for integration and minimal rewrite on the cobol side because we can call cobol programs directly.
-When performing tests for multi-lingual etc, Unicode data can be passed from .NET to cobol and back again in a loop maintaining all the Unicode characteristics
-When passing Unicode data from.NET to a cobol program and writing the record, then retrieve the same data the data is converted and written as ??? which indicates it does not support unicode

Look forward to hearing if anyone has overcome this.

Thank-you.
0 Likes
3 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] Unicode Options with Acu4GL eXtend products

Hello there,

I am a Support Engineer at Micro Focus. Not too long ago (early June 09) a customer in the Netherlands raised a call with us querying about the support in Acu4GL for reading/writing to an Oracle 10g Release 2 database of multi-byte character set. The scenario is such...

Customer has recently started shipping orders to Poland and the current character set (WE8ISO8859P1 - i.e. Western Europe) does not support Polish characters,
Exported the existing data from the database to a .dmp file using Oracle's "exp" utility,
Changed the database character set to 'AL32UTF8' (each character can be up to 4-bytes long),
Imported the data from the .dmp file using Oracle's "imp" utility (creates the tables and inserts the data),
Reading from the new database fails.

Note that the data being read was still all single-byte ASCII character values. I was able to reproduce this problem and a Runtime trace showed that the KEY value to read against was being treated as a complete 40-byte value - those single-byte characters appended with spaces (0x20) up to a 40-byte length. The Oracle database held these values in as long a length as is required.

A workaround solution was proposed that involves altering the table to change the CHAR columns to VARCHAR2; and amending the COBOL source code to treat the corresponding PIC X data items as variable-length with the directive $XFD VAR_LENGTH. The user running the program would have the environment variable NLS_LANG set to their locale. We tested this in-house and we could read the existing data, but it was not feasible for the customer to change CHAR columns in all tables to VARCHAR2 and amend the COBOL source code, recompile and redeploy. Note also that the tests so far have all been with the existing single-byte data. The one Gisle may be able to say if such a solution will/will not work with double (or more) -byte data. Until we don't fully support Unicode in Acu, we cannot confirm any proposed solutions as final.

There is an RPI raised for this issue. A lot of work has gone into it and I believe we have a fix to read/write to an Oracle database with character set "AL32UTF8". I have not got hold of this fix as yet and am keen to see the results, with multi-byte values too. I will post again when I have done...
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Unicode Options with Acu4GL eXtend products

Hi There,

Thanks for the repsonse. We have a UTF8 oracle database already and all our scripts use VARCHAR etc no problem. We can read & write double byte characters etc successfully.

Our issue is more around the abillity to write multiple charcaters from an english server without having to change the regional (non-unicode) settings on the server to write the data correctly. For example. Currently if we want to write japanese characters, the regional (non-unicode) settings on the server must be japanese. If we want to write greek characters we have to change the regional (non-unicode) settings on the server to Greek.

In an environment where all the data is being written from the server we cannot have a specific non-unicode regional setting because multiple countries are entering data and hence are doing the writing.

Has there been any discussion on options for this particular problem.

Thank-you.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Unicode Options with Acu4GL eXtend products

Hi,

the problem is that the automatic conversion happening inside the software does not allow you to have a variable locale. It is possible to have a variable locale provided for the conversion routine, but as of yet such a feature is not yet there.

As you state, when the incorrect locale is being used, you will get question marks, where the unicode character does not fit in with the current locale for the singlebyte codepage in charge.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.