[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SLUG DIALNET materials
In Genera 8.0 dialnet registries are obsolete. Instead, domain files
are used, and a tool is provided to perform the initial conversion from
one format to the other. (see
SYS:DIALNET;CONVERTING-DIALNET-REGISTRIES-TO-DOMAIN-AND-SUBNET-FILES.LISP)
Currently, dialnet registries still load in Genera 8.0 (with a warning),
but this will not continue indefinitely.
The conversion tool writes out a domain file for each of the standard
dialnet registries, and a separate SYS:SITE;SUBNETS.LISP file.
(which, by the way, is not really a lisp file)
The system administrator must add lines to your site's launch file to point
to the three domain files.
SYS:SITE;SUBNETS.LISP is automatically loaded by
the 8.0 mailer.
An example of SYS:SITE;LAUNCH-DOMAIN-SERVER.TEXT follows:
;;;
;;;
;;; this is standard dialnet:
domain varian.dialnet.symbolics.com
primary varian.dialnet.symbolics.com sys:site;varian-domain.text
;;;
;;;
;;; these used to be the dialnet registries (pre-8.0). Subnets are loaded automatically
;;; from sys:site;subnets.lisp
primary dialnet.symbolics.com sys:site;private-dialnet-domain.text
primary dialnet.symbolics.com sys:site;users-group-dialnet-domain.text
primary symbolics.com sys:site;public-dialnet-domain.text
;;;;
After conversion, people are meant to maintain the files in domain file
format (as opposed to maintaining them in registry format and using the
conversion tool each time a change is made).
The following items are now available
from SLUG for people running DIALNET:
(A)- The current SLUG DIALNET user database in domain format (new DIALNET)
(B)- The current SLUG DIALNET user database in registry format. (old DIALNET)
(C)- A Symbolics fix for an error that occurs when loading DIALNET REGISTRIES into
8.0 (DIALNET domain files load without problems)
(D)- A SLUG DIALNET patch that enables messages addressed to internet domains
to be automatically routed to an internet host for forwarding.
i.e, you can address your messages "user@somehost.somedomain.com" instead
of "user%somehost.somedomain.com@riverside.scrc.symbolics.com" .
The patch works in 8.0, and probably in 7.2
Please indicate which sets of these items you want by ending your subject line
with the phrase "[slug dialnet set <num>]" (no quotes), where:
[slug dialnet set 1] This is appropriate for people who will be running
Dialnet in Genera 8.0 using domain files for the dialnet database.
It includes items (A), (C) and (D). This is the preferred dialnet operation.
[slug dialnet set 2] This is appropriate for people who will be running
Dialnet in Genera 7.* using registries for the dialnet database.
It includes items (B) and (D). This is for people who haven't yet
converted to 8.0.
[slug dialnet set 3]
All four items, (A) (B) (C) (D)
WARNING: The Genera 8.0 on-line documentation for DIALNET is incorrect.
It describes the obsolete registry system rather than the new dialnet
domain system. The hardcopy
domumentation (see SITE OPERATIONS) seems to be substantially correct,
although note that the example launch file on p.303 of the hard-copy
SITE OPERATIONS has dialnet entries rather than the correct domain
files.
Regards,
Joe Karnicky
<JFK@BOLD-EAFrom IU.AI.SRI.COM!Warbucks.AI.SRI.COM!slug-admin Mon Sep 17 17:24:12 1990
Received: from IU.AI.SRI.COM ([128.18.60.10]) by neat.cs.toronto.edu with SMTP id <8924>; Mon, 17 Sep 1990 17:23:20 -0400
Received: from Warbucks.AI.SRI.COM by IU.AI.SRI.COM via SMTP with TCP;
Mon, 17 Sep 90 11:09:31-PST
Received: from meillet.ila.com by Warbucks.AI.SRI.COM with INTERNET ;
Mon, 17 Sep 90 11:07:07 PDT
Received: from KILIMANJARO.ILA.COM (KILAMANJARO.ILA.COM) by
meillet.ila.com (4.1/ILA-4.10) id AA17453; Mon, 17 Sep 90 14:05:20 EDT
Date: Mon, 17 Sep 1990 14:17:00 -0400
From: RWK@fuji.ila.com (Robert W. Kerns)
Subject: Translator
To: Reti@riverside.scrc.symbolics.com, RWK@fuji.ila.com, barmar@think.com
cc: kddlab!atr-ln.atr.co.jp!myers@uunet.uu.net, slug@Warbucks.AI.SRI.COM
In-Reply-To: <19900916203038.5.RETI@ZUGSPITZE.sreti.symbolics.com>
Message-Id: <19900917181757.4.RWK@KILIMANJARO.ILA.COM>
Date: Sun, 16 Sep 90 16:30 EDT
From: Reti@Riverside.scrc.symbolics.com
Date: Sat, 15 Sep 90 14:41 EDT
From: RWK@fuji.ila.com (Robert W. Kerns)
Date: Sat, 15 Sep 90 11:14 EDT
From: Kalman Reti <Reti@WESER.sreti.symbolics.com>
An intermediate strategy is to store the location of the function cell
(LOCF #'rewrite-function) and then use LOCATION-CONTENTS in conjunction with
the APPLY or FUNCALL. This will get the new definition when a redefinition
occurs, but will avoid the paging overhead of having to reference the symbol
(which is likely to be far away from the function cell).
This still adds significant paging overhead unless the function cell
is co-located with the function, which is the case sometimes with
Genera and sometimes not. (I couldn't give the current criteria).
Isn't this generally true in modern releases of Genera? I thought that's what
the 'optimize functions' phase of disk-save did. Clearly, my advice was predicated
on my belief that this was true.
It's not true for generic functions, or interpreted functions.
(It's not true until you disk save, if you've redefined the
functions in question, but obsolete functions don't seem like
an important case!). But when I wrote this paragraph, I had
forgotten that function cells that can't live in the functions
generally get put in the symbol-cells table, and thus get
co-located with each other, which isn't so bad.
However, another advantage of my suggestions re: hash tables
is that this technique is pure common-lisp and thus is portable.
Locatives are not. So I still stand by my earlier recommendations,
even though the performance differences between mine and yours
is negligable.
GLE.VARIAN.DIALNET,SYMBOLICS.COM>