[2255] in Release_Engineering
[Liz_Hines@transarc.com: AFS System Types]
daemon@ATHENA.MIT.EDU (Richard Basch)
Sun Apr 15 01:45:22 1990
Date: Sun, 15 Apr 90 01:44:46 -0400
To: release@MIT.EDU, rel-eng@MIT.EDU
From: Richard Basch <probe@MIT.EDU>
What do we want to do about this? (This message is being cc'd to
rel-eng in case anyone wishes to comment prior to this item that I am
proposing for the agenda at Wednesday's RE/QA meeting).
As we continue with AFS, we should move to the new standard @sys
convention, which should be fully decided in the next couple weeks (the
product release goes out before we start friendly test).
I would like to discuss the various alternatives at the next RE/QA
meeting on Wednesday.
As I see it, we have to be using the new @sys convention before the
Fall, which is when it is proposed that we start more widely using AFS.
If we opt not to use Transarc's @sys convention, we will be unable to
easily reference data at other cells, for we must constantly remember
the new standard and our current standards. The question is how much do
we want to break things over the summer.
There are basically two possibilities if we want to adopt Transarc's
sysname convention by the Fall:
1) Change it in the 7.0 release. A warning could go out as soon as
we have Transarc's new naming convention. I expect that most of
the @sys directories will be fixed very quickly (with compatibility
symlinks for the change).
2) Wait for 7.1 and change it then. This gives people more time to
act on it, but it is difficult to know whether all of them have
been changed until the default changes.
I prefer #1, as I would rather not see people discovering breakage
during the fall term. With #1, there may be one or two links missed,
but it is not likely. With #2, it is a lot more likely more will be
missed. I expect that during the friendly-test and staff-test stages,
that most of the links will be corrected in case #1. I expect that the
summer usage will catch the infrequent cases; possibly leaving one or
two to be discovered down the road.
With #2, we don't get the user community flaming at us until it is in
the middle of a "real" term. It would be best not to hinder on the
students' work on Athena by having them discover that something has not
been setup correctly. Admittedly, there is a summer term, but a lot of
Athena usage during the summer is not for papers, etc.
(Considering I am also acting as one of the maintainers of the Athena
cell, I would prefer the extra time to find all the references we use to
@sys; there are a lot of volumes maintained by the AFS administrators,
but I am actually willing to act quickly a little prior to the friendly
test release and take the flak during friendly test for links that I
missed; of course, I can't deal with volumes I don't manage).
An announcement can be made very easily:
staff
sipb
usermsgs
cfyi
with a list of all top-level directories that are user/project/other
volumes, in a format like:
/afs/athena/
astaff/project/
XView
accounts
adt
...
astaff/reference/
...
contrib/
...
course/
...
project/
...
service/
system/
. (it uses @sys here)
afsuser
krbuser
...
user/a/
...
user/b/
...
-Richard
------- Forwarded Message
Date: Fri, 13 Apr 1990 16:13:49 -0400 (EDT)
From: Liz_Hines@transarc.com
To: bww@mtxinu.com, cak@ifs.umich.edu, dan@faraday.ece.cmu.edu,
dimitris+@VEGA.FAC.CS.CMU.EDU, Gregg Lebovitz <gregg+@andrew.cmu.edu>,
kriso@northstar.dartmouth.edu, Mike.Accetta@cs.cmu.edu,
mts@umix.cc.umich.edu, oester@ibm.com, probe@ATHENA.MIT.EDU,
David VanRyzin <vanryzin+@andrew.cmu.edu>
Subject: AFS System Types
Cc: Marybeth_Schultz@transarc.com, Liz_Hines@transarc.com,
Linda_Walmer@transarc.com, David_Stephenson@transarc.com,
Butch_Anton@transarc.com, Mike_Kazar@transarc.com
Hi folks!!
We were asked (quite a while ago) to come up with standard and
consistent system names or types. Well, I figured I had until the
product release to decide on this, so I have procrastinated until
the last possible time!!
The standard for system names is :
<hardware>_<os><version number>
Typically we have used 2 digits for the version number, but that does
not seem to be consistent across operating systems. Also, I could not
come up with a suitable operating system name for Sun systems, so I
omitted it.
I know that converting to these will cause some headaches, but I think
most of those can be handled via links. I know that the inconsistency
with ATK will still cause problems, but I really want to come up with
a scheme that will work in the future.
Please send me any comments by Tuesday, April 17 (I know it is short
notice).
Thanks,
Liz Hines
--------------------------------
The following are Transarc supported values for @sys:
rt_aos4 IBM-RT/PC, AOS Release 4
rt_aix221 IBM-RT/PC, AIX 2.2.1
vax_ul3 Vax, Ultrix 3.0, 3.1
pmax_ul3 Mips, Ultrix 3.1
sun3_35 Sun3, Sun OS 3.5
sun3_40 Sun 3 (68020), Sun OS 4.0.3
sun3x_40 Sun 3 (68030), Sun OS 4.0.3
sun4_40 Sun 4, Sun OS 4.0.3
sun4c_40 Sun Sparcstation 1, Sun OS 4.0.3c
The following are Transarc recommended values for @sys:
rt_machxx IBM-RT/PC, Mach/4.3BSD version xx
rs_aix31 IBM-RS6000, AIX 3.1
vax_bsd43 VAX, BSD 4.3
vax_machxx DEC Vax nnn and/or MicroVax nnn, Mach/4.3BSD version xx
pmax_machxx DECstation 3100 (MIPS), Mach/4.3BSD version xx
sun3_machxx Sun-3/nnn, Mach/4.3BSD version xx
sun4_machxx Sun-4/nnn and/or Sparcstation nnn, Mach/4.3BSD version xx
ymp_uni50 Cray YMP, UNICOS 5.0.12
mac2_mach51 Apple Macintosh, Mach 5.1
mmax_machxx Encore Multimax, Mach/4.3BSD version xx
hp300_ux70 HP 9000/3xx, HP-UX 7.0
------- End Forwarded Message
