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

Reply via email to