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/
---------------------------------------------------                   


Thu, 17 Aug 2000 18:05:48 -0400
Jim Jennis <jhjennis@shentel.net>
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@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, Pennsylvania 19026

Thu, 12 Oct 2000 14:43:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Postgres for OpenVMS