Thread: PostgreSQL on z/OS UNIX?
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? Thanks, Gord Tomlin
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
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 > >
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
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
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 otherdifferences. If at all possible, use ASCII! Cheers, Gavin (Who used to live in EBCDIC land, many, many moons ago)
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 > >
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