Freeware PostgreSQL/iX for HP e3000 MPE
http://www.bixby.org/mark/postgresqlix.html
Freeware RDBMS for MPE
Last updated June 29, 2001 @ 0300 UTC
What's New
- June 28, 2001
- Updated to v7.1.2. Significant features since 7.0.3
include
support
for rows of unlimited length and Write Ahead Logging (WAL -- which
works
sort of like XM on MPE in terms of assuring integrity and improving
performance).
- PostgreSQL was recently announced
as the Red Hat Database commercial product.
- March 25, 2001
- Initial public release of PostgreSQL 7.0.3 for MPE.
- March 9, 2001
- First run of regression tests achieved. This is the
equivalent of
"Hello World!".
Welcome
This is the official home page for the HP
e3000 MPE/iX port of the PostgreSQL
RDBMS . Check here for the latest news, implemented functionality,
known bugs, to-do list, etc. Status reports about major milestones will
also be posted to the HP3000-L
mailing list and its associated gatewayed newsgroup comp.sys.hp.mpe.
Please send your comments, questions, and bug reports directly to
me,
Mark
Bixby.
Or just post them to HP3000-L.
Note that PostgreSQL and other bixby.org ports are strictly the
personal
initiative of Mark Bixby and are IN NO WAY related to any current or
future
product plans of HP CSY.
System Requirements
- Requires MPE/iX 6.0 or later. But note that bixby.org is
now
using
6.5 as the primary development platform.
- Requires GNU
gcc if you want to optionally compile the source code
yourself.
Bixby.org is currently using gcc version 2.95.2.
How to Obtain PostgreSQL/iX
- Download PostgreSQL using either FTP.ARPA.SYS or some other client
- Extract the installation script
- Edit the installation script
- Run the installation script
Download PostgreSQL using FTP.ARPA.SYS from your HP e3000 (the
preferred
method).....
:HELLO MANAGER.SYS
:XEQ FTP.ARPA.SYS
open ftp.bixby.org
anonymous
your@email.address
bytestream
cd /pub/mpe
get postgresql-7.1.2-mpe.tar.Z /tmp/postgresql.tar.Z;disc=2147483647
exit
.....Or download using some other generic web or ftp client (the
alternate
method)
Download the following files (make sure that you use "binary mode" or
whatever
client feature that is 8-bit clean):
Upload those files to your HP e3000 in an 8-bit clean bytestream manner
to:
Then extract the installation script (after both download methods)
:CHDIR /tmp
:XEQ TAR.HPBIN.SYS 'xvfopz /tmp/postgresql.tar.Z INSTALL'
Edit the installation script
Examine the accounting structure creation commands and modify if
necessary
(adding additional capabilities, choosing a non-system volume set,
etc).
:XEQ VI.HPBIN.SYS /tmp/INSTALL
Run the installation script
The POSTGRES accounting structure will be created and then all files
will
be extracted from the archive.
:XEQ SH.HPBIN.SYS /tmp/INSTALL
The New bixby.org Freeware Distribution Architecture
The Old Scheme (never used with PostgreSQL)
An MPE account and a PUB group would be created if they did not already
exist; existing objects will have their attributes altered. All
files
in the tar archive would be extract below this PUB group.
Users would need to customize various files such as job streams and
configuration files residing in the same directories as unmodified
bixby.org
files. Segregating your own local modifications was sometimes
difficult.
New releases would overlay the files from previous releases.
If
you had a problem and wanted to revert back to the previous version of
the software, you would have to restore the entire account.
The New Scheme
An MPE account, a PUB group, and a version-specific group Vvvuuffp
(version,
update, fix, patchlevel) are created if they do not already exist;
existing
objects will have their attributes altered. All files in the tar
archive will be extracted below the version-specific group.
The installation script will create a current version symlink named
CURRENT that points to the active version-specific group, i.e.:
cd /ACCOUNT
ln -s Vvvuuffp CURRENT
Next, the installation script will create possibly multiple symlinks
below
the PUB group that point indirectly via the CURRENT symlink into the
version-specific
group, i.e.:
cd /ACCOUNT/PUB
ln -s ../CURRENT/bin bin
These indirect symlinks allow old-scheme filename references to
continue
to work, and should always be used when referring to objects in the
version-specific
group in order to permit easy upgrading or backdating. For
example,
instead of referring to /ACCOUNT/Vvvuuffp/bin/someprogram, use
/ACCOUNT/PUB/bin/someprogram.
When you upgrade or backdate, the symlink-based filenames will point to
files of the proper version as determined by the single CURRENT
symlink.
The installation script is conservative when creating
symlinks.
If the intended name already exists as a symlink, the old symlink is
removed,
and the new symlink is created. If the intended name already
exists
as a non-symlink, the old object is renamed with a .bak extension, and
the new symlink is created.
Finally, the installation script will create various files and
directories
below the PUB group that are intended for user customization. You
should only modify or add files below the PUB group, and NEVER below
the
version-specific group! The version-specific group is intended to
contain only unmodified files and directories as distributed by
bixby.org.
The PUB group is the proper place for user-customizations.
If you are performing an upgrade, the previous version-specific
group
IS NOT PURGED. If you encounter problems with the new version and
want to backdate, simply purge the CURRENT symlink and recreate it so
that
it points to the previous version-specific group. If you are
satisified
with the new version, you will want to manually do a :PURGEGROUP on the
previous version-specific group to remove it from your machine.
Key Benefits of the New Scheme
- Multiple versions can exist on the same machine in the same
account,
allowing
for worry-free upgrading and backdating.
- User-customized data is kept segregated in the PUB group away
from the
bixby.org data in the version-specific group.
Please let me know what you think about this new scheme because I plan
to use it for other bixby.org software releases. If this scheme
is
well-received, it may even show up in HP CSY Internet &
Interoperability
products.
Distribution Highlights
- /POSTGRES/
- The MPE account for the freeware version of PostgreSQL/iX.
- CURRENT/
- Symlink pointing to the V0701020/ version-specific group.
- PUB/
- MPE group containing user-customizable stuff.
- .profile
- Suggested account shell profile pointing to
../CURRENT/etc/profile.
- public_html/
- .htaccess
- Modified to include Options +Indexes.
- doc
- Symlink pointing to ../../CURRENT/doc.
- V0701020/
- MPE group containing files and directories distributed by
bixby.org.
DO NOT MODIFY ANYTHING IN THIS DIRECTORY TREE! If you need to
customize,
please copy files to the PUB group and customize there.
- INSTALL
- the one-time installation script you ran above
- JBIGTEST
- Sample job stream for running the big, monsterous regression
tests.
Requires initdb to be run previously to create the database directory
tree
and a postmaster to already be running. WARNING: this takes 6
hours
to run on a 989-400.
- JPARTEST
- Sample job stream for running the parallel regression
tests. Requires
initdb to be run previously to create the database directory tree and a
postmaster to already be running.
- JPOSTMST
- Sample job stream for starting the postmaster server daemon.
- JSERTEST
- Sample job stream for running the serial regression
tests. Requires
initdb to be run previously to create the database directory tree and a
postmaster to already be running.
- README
- what you're reading now
- bin/
- All of the PostgreSQL executable scripts and programs,
including the postmaster
daemon and the psql client.
- doc/
- Extensive HTML documentation accessible via
http://yourhost/~MGR.POSTGRES/doc.
- etc/
- postmaster.pid
- The POSIX pid of the postmaster daemon as started by the
JPOSTMST job.
- profile
- Sets various PostgreSQL environment variables to default
values and adds
stuff to the POSIX PATH.
- include/
- Compile-time header files required by the various PostgreSQL
API libraries.
- man/
- Man page documentation for the command line utilities and
psql statements.
- lib/
- Various API libraries, including run-time extensions
dynamically loaded
by the postmaster daemon.
- mpebin/
- Various scripts used to build PostgreSQL/iX from source on
MPE.
- src/
- Source tree.
How to Compile PostgreSQL (optional)
The current MPE build environment relies upon a new feature of ld v0.16
in order to convenient check for unresolved external
references. This feature is enabled by setting the AUTOCONF
environment variable to
1, which is done inside of the configure.mpe script.
Unfortunately at the time of this writing, ld v0.16 is not yet
available
as part of the GNU gcc bundle on jazz. However, a workaround
exists
if you use /usr/local/bin/autoconf from the GNU gcc bundle on jazz to
regenerate
the vanilla PostgreSQL configure script from the configure.in
template.
The regenerated script will then be able to detect unresolved external
references.
- :HELLO MGR.POSTGRES,V0701020
- :XEQ SH.HPBIN.SYS -L
- cd src/postgresql-7.1.2-mpe
- # regenerate configure from configure.in here if you lack ld
v0.16
- configure.mpe
- make
- make install
How to Create the Database Directory Tree
- :HELLO MGR.POSTGRES,PUB
- :XEQ SH.HPBIN.SYS -L
- mkdir data
- initdb
How to Start the PostgreSQL Postmaster Daemon
- :STREAM JPOSTMST.CURRENT.POSTGRES
How to Use PostgreSQL
I have no idea. Really.
I had no prior experience with PostgreSQL when I starting porting
it
to MPE. The only stuff I know about it is how to:
- compile it
- install it
- create the database directory tree with the initdb command line
utility
- run the regression tests
- execute SQL commands with the psql command line utility
For information on how to use PostgreSQL, please consult your local
HTML documentation, your local man pages, or http://www.postgresql.org/.
For ODBC driver information, see ftp://ftp.postgresql.org/pub/odbc/index.html.
For JDBC driver information, see http://jdbc.postgresql.org/.
If you're unable to find the answers to your questions from the
above
resources, your next step should be a public posting to the HP3000-L
mailing
list or the Usenet newsgroup comp.sys.hp.mpe. I will respond if
your
question is related to any MPE porting issues within PostgreSQL, and if
you're asking general PostgreSQL how-to type questions, hopefully other
members of the MPE community who have PostgreSQL experience from other
platforms will be able to respond.
How to Shut Down the PostgreSQL Postmaster Daemon
The postmaster uses System V shared memory and semaphore structures
that
are only cleaned up properly by a controlled shutdown. If you do
not shut down cleanly (i.e. :ABORTJOB), the next run of the postmaster
may behave strangely. To manually clean up shared memory and
semaphores,
use the :IPCS command to display these data structures, and :IPCRM to
remove
them.
Steps for doing a controlled shutdown of the postmaster:
- :XEQ SH.HPBIN.SYS -L
- kill $(cat /POSTGRES/CURRENT/etc/postmaster.pid)
MPE/iX Implementation Considerations
- Because only AF_INET sockets are supported at initial release,
you
generally
need to invoke most PostgreSQL command line clients with "-h localhost"
parameters in order to talk to your local postmaster.
- MPE lacks a SIGWINCH signal, so the postmaster debugging
functionality
triggered by this signal is unavailable on MPE.
- Triggers and procedure code written in Perl are not supported
at
initial
release.
- SSL is not supported at initial release.
- Unless otherwise used by the regression tests, the various
PostgreSQL
programming
API libraries and SQL pre-processor are completely untested.
- You will get compiler errors if the configure script sees the
libbsd
library
from http://jazz.external.hp.com/src/bsd/libbsd.html.
This library is deprecated and should no longer be used; please use the
Porting Wrappers from http://jazz.external.hp.com/src/px_wrappers/index.html
instead. If you absolutely must retain libbsd on your machine,
please
rename it to a location where the configure script won't find it.
Note that PostgreSQL does NOT require either libbsd or the Porting
Wrappers
in order to compile.
Known Bugs Under Investigation
- AF_UNIX sockets for postmaster and client don't work at initial
release.
Use standard Internet AF_INET sockets instead.
- The Makefile relationships between src/backend/port/mpeix and
the upper
levels aren't quite right, with dependencies and targets not always
behaving
properly. If you have already done a build and then edit the MPE
stuff and rebuild, check closely to make sure stuff is relinked with
your
MPE changes. If this didn't happen, purge
src/backend/port/SUBSYS.o
and rerun the make.
- I've seen sporadic transient errors of varying types in varying
tests
of
the parallel regression suite. But there are plenty of times when
the parallel suite runs to completion without any errors.
To-Do List
- Submit MPE diffs back to postgresql.org.
Change History
Mark Bixby