Dear users of ICU,
If you know what EBCDIC is, or what an IBM mainframe is, please read. There are two important questions here.
Short intro: A long time ago, we ported ICU4C to IBM mainframes (OS/390, z/OS) and other native-EBCDIC platforms (OS/400, i5/OS). That is, we added and used special code for ICU to compile and run on a machine where the system charset (encoding, codepage) is in the EBCDIC family rather than assuming the ASCII encoding of the "basic character set".
1. Do you need ICU to work on EBCDIC platforms?
2. If so, can you provide an engineer's time to fix EBCDIC porting bugs, and provide resources for frequent (ideally continuous) testing?
If no one needs this and/or if no one can help make it work and keep it working, then we will probably remove the support code that makes this possible.
Please respond by November 24 if you need EBCDIC and can help support it.ICU4C probably has not been tested on EBCDIC platforms at least since
ICU 59 (2017-apr) moved to C++11. We do not know if there are compilers for any of these platforms which support enough of C++11 now for ICU4C to work. (We are also looking at when to move to requiring C++14 or C++17.)
In other words, you may need to deal with C++ compiler issues as well.
As for EBCDIC, some of us with enough experience have been trying to keep this portability aspect going by sheer attention in code reviews, but mistakes are easy and bit rot is very likely. For example, assuming that 'a'==u'a', or that 'a'..'z' is one contiguous range of byte values, or that '@' is always encoded with the same byte value (in codepages of the same family).
Note: This has little to do with supporting character conversion for EBCDIC codepages, which is supported regardless of which platform you build & run ICU on. That conversion support just depends on the set of conversion table data files that are included in ICU. It is possible (likely) that we will reduce the set of such files included in ICU by default, but that set is anyway customizable.
If we formally remove any attempt at supporting non-ASCII system charsets, then we can simplify our code and make it easier to maintain, and easier to contribute. Leaving behind platforms that lag extremely with compiler support would help us, too.
Sincerely,
markus