annala@neuro.usc.edu (A J Annala) (08/27/89)
I have a source code copy of public domain ingres version 8.9 dated
June 12, 1989. The most recent SCCS version comment states:
"more portability fixs and locking fixs. Suns seem as good as VAXs now."
I have several questions about public domain ingres:
o Is 8.9 the most recent version of public domain ingres?
o Has anyone installed version 8.9 under Sun OS 4.0.3?
o Does anyone maintain a listing of bug or advice about
repairing such bugs in some public forum?
o If you have used public domain ingres, did it perform
as expected, did you have to make many changes to the
software to accomplish useful work, is public domain
ingress sufficiently bug free to use it as a basis for
additional enhancements?
o Does anyone have an implementation of SQL available for
public domain ingres?
o What companies produce commercial versions of ingres?
Have any companies that produced commercial versions
of ingres gone out of business? If so, who owns the
latest version of their software?
I have appended the READ_ME file from public domain ingres for the
people who might be interested in exploring how ingres works in more
detail than is available from published sources.
A. J. Annala
USC Neural, Informational, and Behavioral Sciences Program
(213)743-3278 [best time 2:00 pm to 4:00 pm and 9:30pm to 2:00 am]
---------------------------------------------------------------------
I N G R E S / 8
This version of INGRES runs on VAX hardware under VM/UNIX, fourth
release. It has, at various times, also been running under VM/UNIX,
third release, and version six on a PDP-11/70. Quite probably it
would adapt quite easily to a version seven system on a PDP-11 also.
The chance of ever getting it running on a non-I/D PDP-11 machine
is very small, although theoretically possible.
INSTALLATION
There exist binaries that are runnable, so no recompilation should
be necessary. To prepare the system for running, perform the
following steps:
1. Create a user ``ingres'' in /etc/passwd. This user must have
the root of the INGRES subtree as its home directory.
2. Log in as ingres.
3. Set up the list of valid INGRES users by typing:
~ingres/bin/usersetup
This sets up everyone on your system as an INGRES user.
For more details, read the ``setup instructions'':
chdir ~ingres/doc/other
nroff howto_setup.nr
CONSULTING & INFORMATION.
This software is unsupported, public domain software. Although we
are interested in feedback, it is impossible for us to make any
commitment to support in a research environment. However, several
companies have already expressed interest in selling and supporting
this code -- I'm sure one of them would be more than happy to help
you out.
If you do want to talk to us, electronic mail is strongly prefered.
We can be reached via Arpanet as "ingres@Berkeley" and via UUCP net as
"ucbvax!ingres". Please DO NOT contact us for availability information,
as the INGRES distribution has been merged into the VM/UNIX distri-
bution; we will be able to do nothing except refer you to them. The
contact for VM/UNIX is the CSRG office, (415) 642-7780.
THE SYSTEM ROAD MAP
Following is a brief description of the directory structure. In
this description, and in all other READ_ME files, "..." represents
the root of the INGRES subtree.
bin
Holds system binaries. This is actually an internal
directory (perhaps we should use lib?) (but lib is
already used) and should in general not be included
in search paths. The only things that will live here
that are intended to be executed directory are various
system support routines, "for madmen only".
data
This is the root of the database subtree. It has a
single entry, a directory called "base". That directory
in turn has a directory for each database. The two
layer scheme is required to insure protection -- data
is mode 700 and base is mode 777. Since the database
directories themselves are mode 777, it is critical to
have data unreadable by mortals, lest your sensitive
data disappear in the night.
demo
The source for the demo database exists in this directory.
Basically, it is just a bunch of files that copy uses.
doc
System documentation exists here. See the READ_ME file
in this directory for a more detailed road map.
files
This is an approximate equivalent to /etc. It includes
a bunch of files that are CRITICAL for the system to run.
See the READ_ME file in this directory for more info.
lib
This contains libraries used for recompilation, and can
be removed if you are not interested in recompiling the
system.
source
The source code of the system, of course.
version
A version code. Not critical, but you should probably
leave it laying around on general principles.
bin7
Copies of the version 7 binaries, they are there so
the "ingconv" program can convert binaries. It should
probably be removed once all the databases have been
converted.
All of this can live anywhere in your filesystem, but there MUST
be a user called "ingres" whose home directory points to it. All
of this code MUST be owned by ingres.
RECOMPILATION
Recompilation is described in source/READ_ME.
CONVERSION
If you have been running ingres version 7, and want to use your
databases under version 8, you will need to run the program
ingconv on each database that you want to convert. The useage
is just "ingconv database".
_________
Changes for version 8.9
This later version of version 8 ingres has many more portability fixs and
seems as solid on a Sun as when last compiled on a VAX.
Common problems/bugs:
header files missing - We do not believe any header files are missing.
There are, however, header files in the ctlmod directory which are
reached properly only when make properly calls cc with -I../ctlmod.
The Makefiles in this distribution are believed to work properly.
The version 7 to version 8 convert program may need the version 7
ksort7 binary in the version 8 bin directory.
The locking system has been slitely cleaned up. Sysmod now works when
ingreslock is running. However, no concurency checking is done on
ordered relations. Access methods for ordered relations and the
locking system both need to be reworked.
ingconv doesn't work right unless run by the appropreate dba of each
database.
Rumor has it that some versions of Ultrix are not consistant with 4.2
BSD regarding fstat on a socket which will cause database corruption if
the lockdriver is run. This is unconfirmed.
Ordered relations are SLOW and NOT locked.