[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Namespaces, etc.
Date: Fri, 12 May 89 22:06:20 EDT
From: jfh@cs.brown.edu
Thanks to the helpful information provided by several people, I now know
how to turn on the Internet-subnet-mask for TCP-IP, so that gatewaying
works fine.
Now I'd like to rebuild my world: I want to throw away most of the (very
outdated) stuff in my namespace, delete all the old logfiles and changes
files, and create one pure, pristine version of the namespace. This should
be saved as math-lisp-objects.1, and I'll start making new changes from there.
My question: How do I do this? What files need to *not* be present when I
boot up the original distribution world, and how do I say "This file is
the objects file" without using the namespace editor, and hence creating
the objects one-at-a-time.
My fear is that this may be a complex question. If someone is willing to
help, but not eager to type, just send me a phone number and I can call.
-John Hughes
Math Department
Brown University
It's not complicated at all. The distribution world doesn't try to guess at
where it is; you have to explicitly invoke the :Set Site or :Define Site
commands, or the NETI:FIND-SITE function, to get a distribution world to
understand its site.
The convention for namespace file names is:
SYS: SITE; <namespace>-NAMESPACE.TEXT
Tells where the other namespace descriptor files live.
SYS: SITE; <namespace>-OBJECTS.TEXT
Describes the current versions of all namespace objects.
SYS: SITE; <namespace>-LOG.TEXT
Contains a line with the timestamp (version number), date, time, brief
description, user name, and previous timestamp for each modification of the
namespace database.
SYS: SITE; <namespace>-CHANGES.TEXT (Optional)
Contains a snapshot of each modified namespace object before and
after modification, for easy identification of changes. This is optional.
To set up a cleaned-up namespace, assuming that the namespace server is also
the SYS host:
1. Edit the <namespace>-OBJECTS.TEXT file and save the cleaned-up version under
a different name.
2. Create a <namespace>-LOG.TEXT file, with a single entry showing that the
namespace was created at the exact time the objects file was saved (extract
the time field from Dired listings, for instance). Save it under an assumed
name too.
3. Create a <namespace>-NAMESPACE.TEXT file and save it under an assumed name
too. For a namespace Foo and a server named Foo-bar, this might look like:
VERSION Foo-bar:>sys>site>foo-namespace-log.text
CHANGES Foo-bar:>sys>site>foo-namespace-changes.text
* Foo-bar:>sys>site>foo-objects.text
The line beginning with "CHANGES" is optional. It is entirely possible that
the existing -NAMESPACE file will work just fine; if so, leave it alone.
4. Cold boot a distribution world on the namespace-server-to-be. Be sure the
network address(es) are set to the correct values for that host in the new
namespace. You may wish to unplug the Ethernet cable until the server world
is saved in step 7 below; this isn't strictly necessary, but may help to avoid
creation of "ghost objects" in the new namespace. (Of course, if the
namespace server is not the SYS host, you will need to leave the net
connected.)
5. Delete or rename the old namespace files, and rename the temporary -OBJECTS
file, -LOG file, and (optionally) -NAMESPACE file to the correct names for
your namespace. The version numbers of the new -OBJECTS and -LOG files should
match, and ideally would be 1 if you really wish to rebuild "from scratch".
It is also possible just to rename the new -OBJECTS file to the name of the
old file, version NEWEST. In this case the existing log file should have a
line added at the end, with a timestamp equal to the version number of the new
-OBJECTS file. (I don't know how this will interact with the -CHANGES log,
though.)
6. Do :Set Site <site-name> local <Chaos address> on the server-to-be. This
loads the namespace. If any errors appear in the data, abort and re-edit the
-OBJECTS file (while still in the distribution namespace), adjust the log file
to match, and repeat this step.
7. Save the resulting world.
8. Build new worlds for the user machines. DO NOT reuse old site-configured
worlds, rebuild from distribution instead. Failure to observe this precaution
may cause "ghost objects" to appear. (Nothing is ever completely deleted from
a multi-homed database...)
I hope this helps. I've used this procedure in the past with great success.
Feel free to send mail if you have any questions or difficulties with this.
-- Chuck Fry
Symbolics Software Support