Does an upgrade from Change 5.2 to Change 5.3.1 = change in character encoding/handling?

10 views
Skip to first unread message

cmtodd

unread,
Oct 29, 2014, 9:49:56 AM10/29/14
to synergy...@googlegroups.com
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
Reply all
Reply to author
Forward
0 new messages