I've not been able to find this specifically documented, nor get a straight answer yet from IBM.
Known:
- We have scripts that read, process, and write character data with various fields in Change (mostly exchange with other systems).
- Some of our data has "special" characters (such as German umlauts).
- Before our upgrade to Change 5.3.1 (from v5.2) these special characters were handled ok, always preserving the display of the characters as intended.
- Since the upgrade we have problems with the characters getting corrupted during this processing and exchange.
- We can read out a field from Change with these special characters, then write them back to another field in another CR with a perl API script, and there is not corruption. So there does not seem to be any corruption with a simple read/write to/from Change.
I do not think there is necessarily any bug with Change, but there does seem to be a difference between v5.2 and v5.3.1 that is causing our scripts to corrupt the encoding somewhere along the way (scripts in perl). Have others run into this problem when upgrading, and if so how did you handled it?
My questions to IBM (not yet answered) Can you tell us,...
Does Change 5.3.1 handled all data (text) as
UTF-8. If so, what details can you provide (esp about how data encoding is
handled when exchanging in/out of Change via the Perl API).
If it does handled test as UTF-8, can you tell
me if this is a change since v5.2? How
was data encoding handled in v5.2?
Thanks,
Todd