Re: Postgres for OpenVMS - Mailing list pgsql-hackers

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@fuentez.com
>        jhjennis@shentel.net
> Web:   http://www.discovery.fuentez.com/
> ---------------------------------------------------                   
> 
> 


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