Skip to Main Content
IBM Sterling


This portal is to open public enhancement requests for IBM Sterling products and services. 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 Functionality already exists
Categories Usability
Created by Guest
Created on Dec 11, 2023

CD Unix- CODEPAGE with "iconv -c" or substitution char

When CODEPAGE parameter is used for a transfer, iconv api is used internally by CD to codepage traduction in CDUnix-Linux and CDzOS (CDWindows doesn't use iconv, it's using Microsfot's API mlang.dll).

When in the content of the source file there is a char that exists in source codepage, but it doesn't exist in destination codepage, appears error MBCS002E.


We need that CD can call optionally to "iconv" api with "-c" option to avoid MBCS002E, accepting that we will have characters not translated correctly.

Another option is the use of a substitution char, f.i '?', for this situations, like another products are doing, f.i. like IBM MQ ManagedFileTransfer with option textReplacementCharacterSequence=<char>

What is your industry? Banking
How will this idea be used?

In cases where the content of file needs to be sent, even though one or several chars can't be translated with CODEPAGE pair

  • Admin
    James Joseph
    Reply
    |
    Oct 23, 2024

    Hi Pau Perez,


    I have discussed the RFE with our CD Unix tech experts again and here are our possible suggestions,


    we would suggest to open a PMR with problem details with statistics so that we'll find an existing way to meet the need. For example, what character exists in the source translation that doesn’t exist in the destination?


    Thanks,

    James

  • Admin
    James Joseph
    Reply
    |
    Jun 12, 2024

    Thank you for taking the time to provide your ideas to IBM. we believe, the above inputs meet your needs hence we are closing the ide. If you have any additional feedback, thoughts or ideas, or if there is anything else I can do, please do not hesitate to reply to this message to continue the conversation. Appreciate your patience.

    Thanks,

    Product Management


  • Admin
    James Joseph
    Reply
    |
    Jun 6, 2024

    Here is the alternative process if the Pnode is CD Z.


    PSHUNIX2 -

    PROCESS -

    SNODE=u6.2.0housto.mmf

    STEP1 -

    COPY -

    TO -

    (DSN=/home/nis01/monty/mytemp/pshunix2.out -

    sysopts=":datatype=text:xlate=no:recdl=x25:" -

    DISP=(RPL) SNODE) -

    FROM -

    (DSN=CSDQA1.TESTFILE.BENCH.M1 PNODE DISP=(SHR) )

    STEP2 -

    RUN TASK -

    (PGM=UNIX) -

    SNODE -

    SYSOPTS=\"iconv -c -f IBM037 -t ISO-8859-1 \ || -

    \/home/nis01/monty/mytemp/pshunix2.out > \ || -

    \/home/nis01/monty/mytemp/pshunix2.out.xlated"\


    Please have a look and let us know your thoughts.


    Thanks,

    Product Management

  • Admin
    James Joseph
    Reply
    |
    May 30, 2024

    If the Pnode is CDZ and Snode is CD Unix , we may need to reverse the run task and share. I'll work with the dev team and share the details.


    Thanks,

    James

  • Guest
    Reply
    |
    May 30, 2024

    Thanks Joseph about recdl documentation, I opened an IBM support case about recdl parameter not documented, and due to this the parameter it's documented.


    But you don't unswered the question about execute run task with "iconv -c ..." when the PNODE it's a z/OS CDNode.

  • Admin
    James Joseph
    Reply
    |
    May 29, 2024

    iconv is a CD Unix Utility and we recommend to run the utility on the Pnode which is CD Unix and follow the copy step. Please follow the run task below,

    step01 run task pnode

    sysopts="iconv -c -f ISO-8859-1 -t IBM037 /home/nis01/monty/mytemp/testFile > /home/nis01/monty/mytemp/testFile.xlated"

    step02 copy

    from

    (

    file = /home/nis01/monty/mytemp/testFile.xlated

    sysopts=":datatype=text:xlate=no:recdl=x25:"

    pnode

    )

    to

    (

    file = MFINC1.DEL.ME

    snode

    disp = rpl

    )


    Please refer the below recdl documentation

    https://www.ibm.com/docs/en/connect-direct/6.3.0?topic=parameters-connectdirect-unix-process

  • Guest
    Reply
    |
    Dec 20, 2023

    James.

    The first alternative doesn't work. The problem is that a char from source file doesn't exists in the destination codepage, so the conversion with UTF16 as intermediate codepage it has no sense.


    The second alternative has a lot of problems, at least in zOS side. How we can do external iconv in a zOS environment where we have MVS datasets and not unix files? How we can write a RUN TASK inside a zOS JCL whre iconv it's not a MVS program (it's a USS program)?

    Where it's documented recdl parámeter ??????????????????

  • Admin
    James Joseph
    Reply
    |
    Dec 20, 2023

    The indicated approach essentially allow files to become corrupted during translation, albeit you are ready to accept the same but eventually “will have characters not translated correctly.”

    Hence We would like to suggest a couple of possible alternatives using existing functionality for customer to consider:

    • Use codepage conversion on both sides of the copy step, converting to a common intermediate page, such as UTF-16, on the source side, and then converting from the intermediate page to the desired page on the destination side.

    • Use a run task to invoke iconv utility on the source side with the desired option(s), then copy the resulting translated file to the destination. Below example translates a text file from ISO-8859-1 to IBM037 and copies it to CDZ using this method. Note: recdl sysopt is used to specify the translated record delimiter, IBM037 LF character, in this case:

    step01 run task pnode

    sysopts="iconv -c -f ISO-8859-1 -t IBM037 /home/nis01/monty/mytemp/testFile > /home/nis01/monty/mytemp/testFile.xlated"

    step02 copy

    from

    (

    file = /home/nis01/monty/mytemp/testFile.xlated

    sysopts=":datatype=text:xlate=no:recdl=x25:"

    pnode

    )

    to

    (

    file = MFINC1.DEL.ME

    snode

    disp = rpl

    )

  • Admin
    James Joseph
    Reply
    |
    Dec 14, 2023

    Thank you for taking the time to share your ideas to IBM. We truly value our relationship with you and appreciate your efforts and willingness to share details about your experience, your recommendations, and ideas. We will soon review the same in the coming weeks and shall get back with a response.

    Thanks,

    Product Management