LANSA accessing Unicode.

[JonB]

Hi,

We run LANSA RDML on the IBMi.
We use the Oracle ERP JDE version A94.
We have JDE files defined in the data dictionary as type “Other.”
We a planning to move from JDE A9.4 to Oracle Enterprise One.
We are going to stay on the IBMi.

Oracle Enterprise One uses the Unicode database.

We have many interactive RDML functions (with Display & Request commands) that run on the IBMi that will need to read/update the Unicode fields in “Other” type files.
Converting all of these functions to RDMLX to run as VL apps is not an option currently.

What options do we have, that will mean we can still run the RDML functions on the IBMi, but the will be able to read/update the Unicode fields from the external files?
Or any other ways forward that you can suggest?

Thank you.

[René Houba]

Hi Jon,

That would be difficult.....

If you still want to show a 5250 DISPLAY or REQUEST, you can not show Unicode data, because that is RDMLX. And an RDMLX LANSA function cannot present a REQUEST, DISPLAY or POP_UP:

REQUEST in RDMLX.PNG (120.26 KiB) Viewed 9268 times

And.... in a RDML function, you cannot present RDMLX fields:

UNICODE filed IN RDML.PNG (73.35 KiB) Viewed 9268 times

What you can try is this (let's say you receive 2 unicode fields from the Oracle database and like to show these on a REQUEST in an RDML LANSA function):
1. Define in the RDML function a workinglist with the two fields.
2. Call in your RDML function a LANSA RDMLX function (in this call command, send over the empty workinglist, because you will automatically receive that back from your RDMLX function).
3. In your RDMLX function get the unicode data from the Oracle table.
4. Move the unicode field data to non rdmlx alpha fields (for example: #std_qsel := #STD_NVARC.AsNativeString).
5. Add an entry to the workinglist.
6. You will receive back the workinglist data, which can be presented in your RDML function.

Kind regards,
René

[JonB]

Thank you René.
We have a large system to update. Several thousand functions with many interactions to the JDE files.

We are currently considering a move to RDMLX.