From: mathog@seqaxp.bio.caltech.edu
Sent: Thursday, August 17, 2000 2:16 PM
To: Info-VAX@Mvb.Saic.Com
Subject: partial port of Postgresql available

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. 

Anyway, good luck to whoever wants to have a shot at this next.

David Mathog
mathog@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech