Re: Postgres for OpenVMS

This is a very nice summary of OpenVMS work for PostgreSQL. That IPC
stuff can be very difficult, so I imagine it would take an experienced
VMS person to get that done.

> Hi Postgresql Developers!
>
> A few weeks ago I posted a message on the pgsql-general list asking about a
> possible port of Postgresql to OpenVMS.
>
> Bruce Momjian (who has a lot of VMS experience) wrote me back explaining
> the difficulties involved in such a port.
>
> Well, since Bruce's note, I have been poking aroung in the VMS community
> and lo and behold, one of my VMS colleagues (David Mathog at Caltech) had
> actually begun to look at this in conjunction with my efforts.
>
> I had an email exchange with David today and I have attached it below. I
> hope the Postgresql team may have an opportunity to look it over and
> (perhaps) consider revisiting the possibility of a "VMS port" of Postgresql
> or at least maybe a "VMS team".
>
> Here is a condensed synopsis of my emails with Dave.
>
> Best Regards (and THANKS FOR A DYNAMITE DATABASE!!!),
>
> Jim
> .......................................................
> I've been looking for an affordable database system for our OpenVMS system,
> so far, with no luck. In that quest I've examined some of the freeware
> database systems. I couldn't make heads or tails of MySql or Interbase
> (especially their build procedures). But a recent slashdot thread on the
> excellent performance of Postgresql convinced me to give it a try.
>
> I only allowed myself one workday for this - if it didn't all fall
> substantially into place by then I wasn't going to pursue it. And it didn't
> get far enough for me to go on within that time limit but somebody else
> may want to pick up the pieces (which will at least save them from having
> to start totally from scratch). The distribution is here:
>
> ftp://seqaxp.bio.caltech.edu/software/pgsql_vms_partial_port.zip
>
> (It's big - 16872 blocks!) Look at aaa_vms_port_notes.txt in the top
> directory, and then to do the partial build do
>
> $ set def [.src]
> $ set ver
> $ @make_vms
>
> The partial port is based on an edited log of a build on Linux/Intel. It is
> pretty depressingly for those of us who hope that OpenVMS has a future to
> watch a large package like this build without a hitch on Linux/Intel, and
> to compile at roughly 100x the rate that is obtained on OpenVMS (due
> entirely to the file IO wrapped up in the 100 or so #include operations
> typical for each module - and the current lack of an effective file caching
> system on OpenVMS.) Anyway, the Linux build supplied enough information to
> put together most (not all) of an OpenVMS build procedure.
>
> The good news is that most of the code seems to be pretty well written -
> for Unix code. By that I mean that while it doesn't conform to any one
> C language standard, the vast majority of it compiled with some combination
> of defined language standards, and the rest could be built with
> /standard=relaxed so long as they didn't also require some Unix API not
> present on VMS. (Just don't expect /warn=(enable=all) to be silent, even
> though it flies through gcc -Wall on linux quietly.) In short, something
> like 95% of it could be compiled cleanly "out of the box", and most of the
> rest of that 5% were routines that need to be replaced anyway. That's a
> lot better than most packages I see. (See aaa_vms_port_notes.txt
> for some of the potential bugs I saw - none of which were resolved.)
>
> The bad news is that the entire IPC section needs to be rewritten to use
> native VMS APIs - but that does also open up the opportunity to make it
> more "cluster" aware. (Thanks to Dan O'Reilly for identifying the "UNIX
> domain sockets" pieces, which I'd never seen before.) Those few of you
> who know your way around the innards of multithreaded OpenVMS web servers
> may be able to make quick work of the rest of the port - the issues left
> unresolved by my work are those already resolved in such servers.
>
> After looking at the Postgresql code it looks like a review their code
> for missing ifdefs, especially HAVE_SYS_PARAM_H may help. Those sorts of
> things are set up by "configure" but I found numerous instances where the
> code did not apply the appropriate #ifdef and I had to put it in. I think
> it also would be good have a look at my port notes as the VMS compiler
> flagged a bunch of things that were either outright bugs or were done in a
> nonportable manner.
>
> For instance
>
> if(foo == -1)
>
> when foo (at least on OpenVMS) is an unsigned int.
>
> The build procedure for this is the poster child for the speed limitations
> currently built into VMS systems. It took forever to chunk through this
> pile of code on my DS10, and something like a minute to do it on RH 5.2/
> Intel on a 400 Mhz PII. (But if you do some line like
>
> $ cc.... source.c
>
> and
>
> $ cc..../preproc source.c
> $ cc.... source.i
>
> you'll find that the compilation of the .i file is about 6 times faster than
> that of the .c, ie, it's all file access time grinding through the includes.)
>
>
> Anyway, good luck to whoever wants to have a shot at this next.
>
>
>
>
>
> ,-,-. ,-,-. ,-,-. ,-,-. ,-
> / / \ \ / / \ \ / / \ \ / / \ \ / /
> \ \ / / \ \ / / \ \ / / \ \ / /
> `-'-' `-'-' `-'-' `-'-'
> --------------------------------------------------------
> FSC - Building Better Information Technology Solutions-
> From the Production Floor to the Customer's Door.
> --------------------------------------------------------
>
> Jim Jennis, Technical Director, Commercial Systems
> Fuentez Systems Concepts, Inc.
> 1 Discovery Place, Suite 2
> Martinsburg, WV. 25401 USA.
>
> Phone: +001 (304) 263-0163 ext 235
> FAX: +001 (304) 263-0702
>
> Email: jjennis(at)fuentez(dot)com
> jhjennis(at)shentel(dot)net
> Web: http://www.discovery.fuentez.com/
> ---------------------------------------------------
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026