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 (

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 ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - 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 Nov 13, 2023

Named constant *SRCCCSID for current source CCSID

Moving files from QRPGLESRC to IFS and around in international environment can cause some challenges for CCSID. However procedures can be written to be aware of this issue and be language (ccsid) neutral by passing the ccsid of the source file containing the caller of your procedure.


By providing a named constant i.e named *SRCCCSID that evaluates to the ccsid of the source this can be achieved.


Lets say you have a QRPGLESRC files in ccsid 500 that calls a procedure in a service program supposed to cater for any (EBCDIC) ccsid - today we need to do something like this:

// Set your delimiter according to your CCSID of your source file if you parse any strings. // Note the "makefile" is set to international - ccsid 500 for all source files


pJson = json_parseString ('{ "name":"Niels"}');


Now with the *SRCCCSID in place we could potentially write the code more generic:


pJson = json_parseString ('{ "name":"Niels"}');

.. and it will work with whatever the (EBCDIC) source ccsid is in scope.

Note: You are able to temporary switch ccsid in the source and therefore the *SRCCCSID should reflect the current ccsid in scope.

Extra feature:

Perhaps an extra feature is to be able to pass the *SRCCCID as a hidden parameter by declaring into the prototype:

Dcl-PR json_parseString pointer extproc(*CWIDEN : 'jx_ParseString');

ccsid uns(5) value options(*srcccsid: *hidden)

string pointer value options(*string);


When we then call it like this.

pJson = json_parseString ('{ "name":"Niels"}');

.. it will under the covers - in this case - expand to :

pJson = json_parseString ( 500: '{ "name":"Niels"}');


It is correct that you can make the conversion by declaring the ccsid on the prototype, however it will not work for options(*string)

This request is based on input from users of the noxDb open source project:

Idea priority Medium
  • Guest
    Jun 10, 2024
    IBM has previously requested more clarifying information. Because the additional information was not provided within 30 days, the request has been closed.
  • Guest
    Jan 17, 2024
    Hi Niels, thank you for your response and your patience :-). However, IBM still needs more information to further assess your Idea.

    We are still having difficulty in understanding your requirement. You mentioned that the target CCSID of a variable can change on the fly, but the TGTCCSID parameter of the CRTRPGMOD and CRTBNDRPG commands only affects the CCSID that will be used to read the source. It does not affect the CCSID of any variables. The CCSID of any variable would always be the same, no matter what CCSID the source is processed in.

    If a variable with CCSID X is loaded with data from a different CCSID Y, then that is a programming error. The RPG compiler would assume that the data was in the same CCSID as the variable, and if the compiler needed to do some CCSID conversion for assignment or parameter passing, it would assume that the data was in the assigned CCSID of the variable. You can't change the CCSID of a variable on the fly. The only time a variable has a CCSID that can change is when the variable is defined to have the job CCSID (that is the default). (But note that if the job CCSID changes while the program is running, RPG would assume that it was still the same as when any procedure in the module is first called.)

    We don't understand what you mean by "bringing the CCSID from the client code into the open source project". That sounds like something that would be done with the source itself, but what you are describing with *TGTCCSID sounds like something that would be done when the program is running, when it is calling something (your APIs?).

    - IBM Power Systems Development
  • Guest
    Jan 16, 2024
    Thank you for your response. However, IBM still needs more information to further assess your Idea. :-)

    The /SET directive only affects the CCSID of variables. It does not affect the CCSID of the literals in the source or the CCSID of the source lines.

    All the lines in the source are read with the same CCSID. If a copy file has a different CCSID, the lines in the coup file are converted to the TGTCCSID.

    If you want to know the CCSID of a particular variable, it would be better to request a built-in function such as %CCSID that would return the CCSID of a variable.

    ctl-opt ccsid(*char : *jobrun);

    dcl-s dft_ccsid_jobrun char(10);
    /set ccsid(*char : 500)
    dcl-s set_dft_ccsid_500 char(10);
    dcl-s explicit_ccsid_utf8 char(10) ccsid(*utf8);
    dcl-s dft_utf16 ucs2(*utf16);
    /restore ccsid(*char)

    If there were a %CCSID built-in function, and the job CCSID was 37:

    %CCSID(dft_ccsid_jobrun) would return 37 (the job CCSID).
    %CCSID(set_dft_ccsid_500) would return 500.
    %CCSID(explicit_ccsid_utf8) would return 1208.
    %CCSID(dft_utf16) would return 1200.

    Would a %CCSID built-in function provide what you need?

    Regarding the CCSID for OPTIONS(*STRING), please open another Idea to request that the CCSID keyword be supported for OPTIONS(*STRING).

    - IBM Power Systems Development
    1 reply
  • Guest
    Jan 11, 2024
    IBM needs more information to further assess your Idea.

    If the IFS source is Unicode, with CCSID 1208, the TGTCCSID parameter would be needed to compile the source. For example, TGTCCSID(500). *SRCCCSID would be 1208 which might not be useful.

    The TGTCCSID parameter can also be specified when compiling source from a source physical file. For example, a source file with CCSID 37 could be compiled with TGTCCSID(500). *SRCCCSID would be 37 which might not be correct.

    The TGTCCSID parameter indicates the CCSID that the compiler uses to read the source, and it indicates the CCSID of the literals stored in the generated module.

    Would it be better to have a way to get the target CCSID instead of the source CCSID?

    - IBM Power Systems Development
    1 reply