[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SYS:SITE; A novice adminstrator's question
Date: Thu, 1 Aug 91 10:45:10 EDT
From: email@example.com (John R. Delaney)
This question is for seasoned Symbolics network adminstrators. It pertains
to managing such a network when you have two (or more) Genera versions
It appears from the instructions for system installation that the file
"SYS:SITE;SYS.TRANSLATIONS" should translate "SYS: **; *.*.*" into
"<some host>:>REL-<majo number>-<minor-number>>SYS>**>*.*.*" using
It appears from the namespace description that the site object site
directory attribute should give the translation for "SYS: SITE;", e.g.,
"<some host>:>SITE>". It would also appear that this translation take
precedence over the above. That is, if I copied a file to "SYS: SITE;
FOO.SYSTEM" some time long after booting, it would end up in "<some
Is that correct?
Yes. You generally don't change sites with each new release!
Especially, you don't change namespaces, and the translation rule
for SYS:SITE; looks in the namespace, as you noticed.
Is that what one really wants? I can conceive of cases
where I want a different .SYSTEM file for different Genera releases.
Actually, it's extremely unlikely you'd want a different .SYSTEM file.
What's far more likely is that you'd want different translations for
different system versions (or even on different machines!). Since
both the .SYSTEM and .TRANSLATIONS files are LOAD'ed, you can just
put in conditionalization to do what you want. That way, when you
install a new version of the system, you don't suddenly find you can't
get at all the software you're used to getting at. 90% of the time,
you aren't going to need separate translations.
Or does the tranbslation specified by the site object site directory
attribute only applies until the SYS.TRANSLATIONS file is loaded?
No. Not unless you replace the translation rule which looks in
The translation rules are not the patterns you give in SYS.TRANSLATIONS,
and they aren't changed by loading SYS.TRANSLATIONS. (You can look at
the translations given in SYS.TRANSLATIONS as being the data that the
normal translation rule uses, but SYS:SITE;**;*.*.* uses a rule that
looks in the namespace instead of the translation table.)
[If you're wondering what all this hair about rules is about, it's to
allow more complex systematic renamings, such as replacing "-" with "_"
for VMS, or various schemes for automatically compressing pathnames
to fit 14 characters for brain-damaged systems distributed by telephone
companies. They're also used to handle patch file names, to avoid an
incompatibility between Genera versions.]
case, I should have only the SYS.TRANSLATION files in the directory
"<somehost>:>SITE>" and all .SYSTEM and other .TRANSLATIONS file in the
directory "<some host>:>REL-<majo number>-<minor-number>>SYS>SITE>".
This makes sense to me. But that is a vote against it being right.
I think the only reason it makes sense to you is that you
are thinking that you'd want to customize the .SYSTEM file.
But if you think a bit more, I'm sure you'll realize that
customizing the .SYSTEM file isn't going to help; the contents
of the .SYSTEM file are really almost constant:
(sct:set-system-source-file "MYSYS" "MYHOST:SYS;SYSDCL.LISP")
The only part that would vary is MYHOST (unlikely to vary
between software versions!) or SYSDCL. I could see you might
want to have two different SYSDCL files in the same directory,
in which case you would write:
(multiple-value-bind (major minor)
(cond ((or (> major 8) (and (= major 8) (> minor 1)))
(sct:set-system-source-file "MYSYS" "MYHOST:SYS;SYSDCL-FUTURE.LISP"))
(t (sct:set-system-source-file "MYSYS" "MYHOST:SYS;SYSDCL.LISP"))))
(Of course, you could actually accomplish the same thing with
the translations file by translating MYHOST:SYS;SYSDCL.LISP
to two different files!)