Spanish Characters In Source Code

[poddys]

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.

[CRPence]

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/eserver/iseries/software/globalization/pdf/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/eserver/iseries/software/globalization/pdf/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]

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.

[CRPence]

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