Hi Tom,
EBCDIC isn't strictly mandatory, but it is the lingua franca of
mainframes, so for most applications not running EBCDIC would result in
constant translation between EBCDIC and ASCII, which can become a
performance issue. The platform does support ASCII and Unicode, but in
most cases you're choosing to put an application on z/OS to interact
with existing applications and data that are in EBCDIC-land. After all,
if you aren't there to access that stuff, why not just run in a Linux
image on the machine (which does not use EBCDIC) instead?
EBCDIC doesn't always have to be a show stopper. There are plenty of
applications that have been ported successfully, and a few (notably
Python) that haven't gone so well. An easy way to get burned is to make
ASCII-centric assumptions about collating order, e.g., c'A' c'1', or
c'A' c'a'. Code that always uses isalpha() and friends should be OK.
Your warning about character sets all being expected to be ASCII
supersets is a concern.
Regards, Gord Tomlin
On 2015-02-24 17:12, Tom Lane wrote:
Gord Tomlin gord.tom...@sympatico.ca writes:
z/OS UNIX does have certification as a UNIX system, but there are some
quirks. The most common sources of problems when porting packages to
z/OS UNIX are its use of EBCDIC, and autoconf problems. I guess it's
time for some fail/rinse/repeat.
Hmm ... EBCDIC ... is that mandatory? Because there are a pretty large
number of ASCII dependencies in PG, mostly arising from our support of
multibyte character sets, which are all expected to be ASCII supersets.
If there's not a way to run the server process in ASCII-land, you're
likely dead in the water. I would not want to try to ferret out all
the dependencies.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
