PostgreSQL on z/OS UNIX?

Gord Tomlin <gord.tomlin@sympatico.ca> writes:

I see that PostgreSQL will run on S/390 and S/390x processors, but I can
find no mention of the z/OS operating system on the web site, in the
documentation or in the mailing list archives.

Has there been a known attempt to port PostgreSQL to z/OS UNIX?

If it's reasonably much like other Unixen, it should Just Work.
Have you tried?

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

Hi Tom,

No, I haven't tried at this point. I thought it would be a good first
step to find out whether anyone else had already tried, in order to
avoid reinventing any wheels.

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.

Thanks, Gord Tomlin

On 2015-02-24 13:37, Tom Lane wrote:

Gord Tomlin <gord.tomlin@sympatico.ca> writes:

I see that PostgreSQL will run on S/390 and S/390x processors, but I can
find no mention of the z/OS operating system on the web site, in the
documentation or in the mailing list archives.

Has there been a known attempt to port PostgreSQL to z/OS UNIX?

If it's reasonably much like other Unixen, it should Just Work.
Have you tried?

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

On Tue, Feb 24, 2015 at 10:31:15AM -0500, Gord Tomlin wrote:

Hello,

I see that PostgreSQL will run on S/390 and S/390x processors, but I
can find no mention of the z/OS operating system on the web site, in
the documentation or in the mailing list archives.

Has there been a known attempt to port PostgreSQL to z/OS UNIX?

I tried this several years back, but failed hard right out of the gate
due to being unable to get access to such a machine.

Is there any chance you can put one or more "animals" of this type on
the buildfarm?

http://buildfarm.postgresql.org/

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Gord Tomlin <gord.tomlin@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

On 25/02/15 11:12, Tom Lane wrote:

Gord Tomlin <gord.tomlin@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

EBCDIC is very strange, lower case letters come before upper case, and each letter range has 2 gaps. There are lots of other differences.

If at all possible, use ASCII!

Cheers,
Gavin

(Who used to live in EBCDIC land, many, many moons ago)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.tomlin@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

Gord Tomlin <gord.tomlin@sympatico.ca> writes:

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'.

The code's kinda full of those, too :-( --- maybe not directly on the
type of case you mention, but there are definitely assumptions that the
codes for letters and numbers are consecutive, which IIRC EBCDIC fails
to do. We've never spent any effort to avoid that.

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