Spanish Characters In Source Code - IBM AS400

This is a discussion on Spanish Characters In Source Code - IBM AS400 ; I need to compile some programs that were written in South America and that contain variables with an enya (N with squiggle on top). The characters are not being recognized, but I'm not sure of the best way to deal ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Spanish Characters In Source Code

  1. Spanish Characters In Source Code

    I need to compile some programs that were written in South America and
    that contain variables with an enya (N with squiggle on top). The
    characters are not being recognized, but I'm not sure of the best way
    to deal with these. I would prefer not to rename all the variables...

    Back in the S/36 days I had the same issue, and managed somehow to
    deal with it by adding something to the RPG H specs, but this was
    virtually 20 years ago and I don't remember exactly what I did. It
    might have even been a character translation/mapping, which might
    equate to the AS400 Code Pages.

    Our AS400 standard is US English. Is there any easy way to deal with
    Spanish characters so that we don't have to change things every time
    we get a new program?

    Thanks in advance.


  2. Re: Spanish Characters In Source Code

    The best resolution is to ensure the original copy of the source is
    created with a CCSID that matches the data being placed into the file,
    and that the target file is also assigned a CCSID. Then the copy or
    restore of the data at the target system needs to maintain/honor that
    CCSID; e.g. convert the data from the original CCSID to the target CCSID
    when the source and target should not match.

    The undesirable method to resolve is to try to treat the data as
    binary [and hope for the best]. If the data is not properly /tagged/
    with the CCSID, then the results are unpredictable, except when the
    origin of the data is created consistently [without regard to proper
    tagging] into the future. Thus if the data origin is always Spanish
    data CCSID(284), then making the target system file CCSID(284) where a
    binary copy into that target would always represent the truth.

    CCSID(284) /* 1145 for Euro */
    http://www-03.ibm.com/servers/eserve...f/cp00284z.pdf
    Char Hex CharName Description
    | 49 SM650000 vertical [broken] bar
    # 69 SM010000 hash
    6A LN190000 enye pequenyo
    7B LN200000 enye grande

    CCSID(37)
    http://www-03.ibm.com/servers/eserve...f/cp00037z.pdf
    Char Hex CharName Description
    49 LN190000 enye pequenyo
    69 LN200000 enye grande
    | 6A SM650000 vertical [broken] bar
    # 7B SM010000 hash

    Probably a safe assumption is that the code compiles properly in its
    original environment; irrespective of tagging. Thus if the compile does
    not work in an alternate environment, then presumably tagging at the
    target [failing location] is different, but the data was not converted.

    Assume the original source was created with CCSID(284), and the data
    arrived at the target without conversion. The variable named HASH#
    [where the fifth byte is the hash character] is x'C8C1E2C869'. When
    that data is viewed at a terminal where the device CHRID() is
    established for an English language, the variable name will appear to be
    the value HASH which is not a valid variable name. If the source is
    not tagged with a CCSID, one that effects no conversion [i.e. has
    CCSID(65535) or CCSID(*HEX)], then the compiler assuming the CCSID is
    the one associated with the Language Identifier [LANGID] will make the
    same false assumption as the visual representation; i.e. the variable
    name is not valid. Same if the source is tagged with CCSID(37), but the
    data as noted, is really CCSID(284).

    Resolve the issues by correcting the source and target file CCSID
    tagging; i.e. assign them with a CCSID other than *HEX|65535, where the
    specified CCSID matches the data being inserted.
    Note: If the origin of the data is not consistent, then an attempted
    correction at the source system may see similar failures to those
    experienced at the target system. In that case, either edit or copy the
    data, to establish the correct data in the now-tagged source.

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    poddys wrote:
    > I need to compile some programs that were written in South America and
    > that contain variables with an enya (N with squiggle on top). The
    > characters are not being recognized, but I'm not sure of the best way
    > to deal with these. I would prefer not to rename all the variables...
    >
    > Back in the S/36 days I had the same issue, and managed somehow to
    > deal with it by adding something to the RPG H specs, but this was
    > virtually 20 years ago and I don't remember exactly what I did. It
    > might have even been a character translation/mapping, which might
    > equate to the AS400 Code Pages.
    >
    > Our AS400 standard is US English. Is there any easy way to deal with
    > Spanish characters so that we don't have to change things every time
    > we get a new program?


  3. Re: Spanish Characters In Source Code

    Thanks very much Chuck, that was very detailed.
    I'm not too sure where to specify the CCSID for the source though.
    I had to upload the program source into my library using Client Access
    as it had been saved as a text file.
    I'm wondering if I specified anything there if that might help with
    the translation.
    It's just program variables I'm having problems with, not data (for
    now at least).
    Thanks again.


  4. Re: Spanish Characters In Source Code

    The text file is a stream of character data which must be known to be
    of a particular encoding. When that character data is input into the
    target source file.member, given known source and target encoding, the
    data will be converted. The source file is created with CRTSRCPF
    CCSID(value), or less desirable to be modified by CHGSRCPF CCSID(value)
    [if that is available].

    I am not clear on what the process of both 'saved as a text file' and
    'upload' are in the scenario, but for the target source file, use DSPFFD
    to review the field CCSID; probably DSPFD srcflib/srcfname *ATR suffices
    in 99% of cases to review the file CCSID which defines all fields
    [albeit 'associated' CCSIDs used for /shifted/ data types]. The CCSID
    value for the source file should probably be either CCSID(284) or
    CCSID(37) for a proper text transfer with conversion. If every system
    was US English, even spanning ASCII & EBCDIC, then an /effective binary/
    transfer would be generally functional; but rarely is anything so simple.

    Note: A true binary transfer would have ASCII data in the EBCDIC
    source file. An effective binary transfer implies the case of ASCII to
    EBCDIC without regard to any specific EBCDIC CCSID; i.e. when a transfer
    is done into a source file created with CRTSRCPF CCSID(*HEX). When the
    target file is properly tagged [i.e. other than *HEX|65535], then the
    transfer should work fine; that is why tagging the file(s) is the
    appropriate resolution.

    Here is a script from which one might infer details about [to see and
    to set] the /tagging/ a source file with a CCSID:

    dltf qgpl/dltmesrc
    chgjob ccsid(*hex) langid(esp)
    wrkjob option(*dfna) /* default job CCSID 284 */
    crtsrcpf qgpl/dltmesrc ccsid(*job)
    dspffd qgpl/dltmesrc /* field CCSID is a 'soft' 284 */
    chgsrcpf qgpl/dltmesrc ccsid(37 )
    dspffd qgpl/dltmesrc /* field CCSID is a 'soft' 037 */
    dltf qgpl/dltmesrc
    crtsrcpf qgpl/dltmesrc ccsid(285 )
    dspffd qgpl/dltmesrc /* field CCSID is a 'hard' 285 */
    chgsrcpf qgpl/dltmesrc ccsid(37 )
    - Explicitly specified CCSIDs or file restrictions present.
    - File DLTMESRC in QGPL not changed.

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    poddys wrote:
    > Thanks very much Chuck, that was very detailed.
    > I'm not too sure where to specify the CCSID for the source though.
    > I had to upload the program source into my library using Client Access
    > as it had been saved as a text file.
    > I'm wondering if I specified anything there if that might help with
    > the translation.
    > It's just program variables I'm having problems with, not data (for
    > now at least).


+ Reply to Thread