Failure with special character

Previous topic - Next topic

jsquizz

We have an issue when loading a name field.

ARS1127E Row 1:  The string "JUAN CARLOS�‘ORTEGA                                               " has a length of 83 and the field has a maximum length of 80

The special character added by what I am assuming the "�" is causing the field to spill into 83 characters. I've tried removing space, removing tab, etc.

the only fix that I was able to get working in a "timely" matter - is recreate the AG, and for the field info:

String: Case(Mixed)
Type: Variable

IBM suggested that - But I am wondering if anyone knows of a way to do it at the application level so I don't have to recreate an application group.

#CMOD #DB2 #AFP2PDF #TSM #AIX #RHEL #AWS #AZURE #GCP #EVERYTHING

Darrell Bryant

If you have a test environment, you might experiment with the ARS_USE_OLD_STYLE_CASE parameter in the ARS.CFG file.

Use the following if upper casing expands the number of characters, for example the German Ezett (�) expands to SS with the new style (ICU) upper casing
In the ARS.CFG:
# Use old style upper casing to prevent character expansion
#
ARS_USE_OLD_STYLE_CASE=1

When value of ARS_USE_OLD_STYLE_CASE is:

(0) - then we do all upper/lower casing in UTF-16 (no change)
(1) - then we do all upper/lower casing in OS level codepage we are running under (no change)
this was really added just to prevent the german sharp s (�) character not expand to multiple bytes (which it does in UTF-8)
(2) - we now upper/lower case in UTF-16 (however we specifically prevent � from being done).
We then convert this back to the native codepage (of the data) - then compare to the original string that was provided to us.
If we find any characters that are not found (e.g. ICU will change the char to be a substitution char),
we will put the original char back into the upper/lower case string. If for any reason this fails we will
default as if the ARS_USE_OLD_STYLE_CASE=1 for that string.
#IBMi #iSeries #PDF #XML #400 Indexer #ASM

jsquizz

Quote from: Darrell Bryant on March 03, 2023, 01:10:41 PM
If you have a test environment, you might experiment with the ARS_USE_OLD_STYLE_CASE parameter in the ARS.CFG file.

Use the following if upper casing expands the number of characters, for example the German Ezett (�) expands to SS with the new style (ICU) upper casing
In the ARS.CFG:
# Use old style upper casing to prevent character expansion
#
ARS_USE_OLD_STYLE_CASE=1

When value of ARS_USE_OLD_STYLE_CASE is:

(0) - then we do all upper/lower casing in UTF-16 (no change)
(1) - then we do all upper/lower casing in OS level codepage we are running under (no change)
this was really added just to prevent the german sharp s (�) character not expand to multiple bytes (which it does in UTF-8)
(2) - we now upper/lower case in UTF-16 (however we specifically prevent � from being done).
We then convert this back to the native codepage (of the data) - then compare to the original string that was provided to us.
If we find any characters that are not found (e.g. ICU will change the char to be a substitution char),
we will put the original char back into the upper/lower case string. If for any reason this fails we will
default as if the ARS_USE_OLD_STYLE_CASE=1 for that string.

Yup- I saw that as well. Do you know if that requires a recycle of ARSSOCKD? I only ask because we are on Z/OS and we'd have to do some coordination.
#CMOD #DB2 #AFP2PDF #TSM #AIX #RHEL #AWS #AZURE #GCP #EVERYTHING

Darrell Bryant

Any change to ARS.CFG requires a restart of arssockd.
#IBMi #iSeries #PDF #XML #400 Indexer #ASM

jsquizz

Thanks, wasnt sure if it was the same on the mainframe side
#CMOD #DB2 #AFP2PDF #TSM #AIX #RHEL #AWS #AZURE #GCP #EVERYTHING