Skip to Main Content
IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Categories Languages - RPG
Created by Guest
Created on Mar 30, 2017

Upgrading the %XLATE bif

The third parameter of the %XLATE bif is the string to be translated
as per the manual: string = %XLATE(lo:up:'rpg dept');

The problem with this bif is that this string must be defined in the source code. But the the problem is that CCSID's for different environments/companies using the same program may differ. For example, the same may be run in a 273, 37, or 870 environment.

During data exchange/transmission, certain characters may not be used - ever. This applies specifically to data transmission to banks.
For example, the German special characters üÜöÖäÄß and in Poland '¹¥æÆêÊñѳ£óÓœŒŸ¿¯' ---> sorry, don't translate to this page.

This bif would be much more useable should the third parameter allowed to be a field name. Thus, all fields can be dtaara/database-based and therefore less susceptible to CCSID changes.

For example:
// Special chars to be replaced with these
dcl-ds XLTCHARin dtaara(XLTCHARIN);
xltin char(18);
// Special chars to be replaced
dcl-ds XLTCHARout dtaara(XLTCHAROUT);
xltout char(18);

in XLTCHARin;
in XLTCHARout;
adr101 = %xlate(XLTin :XLTout :adr101);
adr102 = %xlate(XLTin :XLTout :adr102);
etc...

In addition... this RFE also applies to the SQL TRANSLATE scalar function. Should a seperate RFE be opened?


Use Case:

As stated, many special characters may not be used during data exchange/transmission. This applies specifically to data transmission to banks.


Idea priority Medium
  • Guest
    Reply
    |
    Jun 19, 2017

    *** Note - This RFE was erroneously set back to "Information Provided" as an IBM Response after it was set to "Declined". Our tools people are working on the problem. Meanwhile, I am setting this RFE back to its intended state, which is "Declined". See next paragraphs for the reason for declining. ***

  • Guest
    Reply
    |
    Apr 7, 2017

    Thank you for the quick reply. I'm glad that both %XLATE and TRANSLATE are working with variables for you :-)

    Since the requested feature is already available, I am declining this RFE.

  • Guest
    Reply
    |
    Apr 7, 2017

    ufff... I have re-instated my (commented out) lines of using the %XLATE with variable only - and now it compiles. Also did the same for the SQL TRANSLATE and it too works. tried with my Polish and German user profiles - both work!!
    I have no idea why they wouldn't compile before and now they do. Darn, I hope that I wasn't having a Senior moment. ;)
    My apologies for the incorrect information.

  • Guest
    Reply
    |
    Apr 6, 2017

    The %XLATE built-in function already allows variables for all of the parameters; this has always been the case. If some other enhancement to %XLATE is needed to solve this issue, please clarify by adding a comment to the RFE.

    Also, please open a separate RFE for the SQL TRANSLATE function. When opening the RFE, specify Brand="Servers and System Software", Family="Power Systems", Product="IBM i", Component="DB2 for i".

  • Guest
    Reply
    |
    Apr 6, 2017

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - Servers and Systems Software
    Product family - Power Systems
    Product - IBM i
    Component - Languages - RPG
    Operating system - IBM i
    Source - ISV (Independent Software Vendor)

    For recording keeping, the previous attributes were:
    Brand - Servers and Systems Software
    Product family - Programming Languages
    Product - Developer for Power Systems
    Component - RPG/COBOL Development Tools
    Operating system - IBM i
    Source - ISV (Independent Software Vendor)

  • Guest
    Reply
    |
    Mar 31, 2017

    A variable name can be used in the 3rd parameter, we use it all the time like that. What would be valuable is adding an optional 4th parameter for a CCSID.