*start*
01410 00024 US 
Date: 7 Sept. 1982 4:19 pm PDT (Tuesday)
From: Fiala.PA
Subject: Re: MAXC ACCOUNT ACTIVITY
In-reply-to: RWeaver's message of 2 Sept. 1982 2:59 pm PDT (Thursday)
To: RWeaver, Cude, Taft, Schroeder
cc: Fiala

For reasons that we discussed several years ago, I think we should move in the
direction of a naming convention for personal directories in which the name is
normally first-initial/last-name rather than normally just last-name.

However, the recent list of new directories in Ron's message included <RAIM>,
<THATCHER>, <FORREST>, and <CROW>, all just last-name.  We recently had
problems with <REID> vs. <BREID>, and as the PA registry increases, we can
expect a growing number of problems (proportional to the square of the number
of names in the registry).

I would like to propose that on new personal directories for people in the PA
registry, we insist on (ordinarily) first-initial/last-name.  Also nickname (e.g.,
<WILLIESUE> and <SMOKEY>) should be disallowed on new directories.

In the past when we tried this, there were various situations which came up
such as a person who came here for the summer with an existing directory at
some ARPA site with differing naming conventions.  We always succumbed to
requests that the name on Maxc/PA be whatever the person wanted.  I propose
that we not succumb any more.

Please answer this proposal with agreement or dissent.

*start*
00426 00024 US 
Date: 8 Sept. 1982 6:29 am PDT (Wednesday)
From: RWeaver.PA
Subject: Re: MAXC ACCOUNT ACTIVITY
In-reply-to: Fiala's message of 7 Sept. 1982 4:19 pm PDT (Tuesday)
To: Fiala
cc: RWeaver, Cude, Taft, Schroeder

Ed,

  I agree with your proposal.  Standardization would certainly simplify things
for me.  Of course there will arise the case where first and second initials may
become necessary.

  Ron...

*start*
01198 00024 US 
Date: 8 Sept. 1982 8:45 am PDT (Wednesday)
From: Taft.PA
Subject: Re: MAXC ACCOUNT ACTIVITY
In-reply-to: Fiala's message of 7 Sept. 1982 4:19 pm PDT (Tuesday)
To: Fiala
cc: RWeaver, Cude, Taft, Schroeder

This idea has come up, been discussed, and been rejected two or three times
before.  I see little advantage in enforcing such a convention uniformly.  The
PA registry is now large enough that all the common names are already taken; a
new Smith or Brown who comes along will necessarily be called MSmith or
KBrown.  Less common names are less likely to be duplicated anyway.

If we were redoing the entire PA registry, there might be some advantage to a
uniform naming structure, since it would make people's Grapevine R-names
easier to remember.  But given the large existing community of
haphazardly-chosen names, there is no advantage in imposing uniformity on
new names.  Finding out an unfamiliar person's Grapevine R-name will still
require looking it up in the PARC phone list or the RINN white pages, since how
can one know whether a name was assigned before or after the uniform naming
convention was instituted?

Therefore, I am opposed to this proposal.
	Ed

*start*
00530 00024 US 
Date:  4-Feb-83 10:33:10 PST (Friday)
From: Kierr.pa
Subject: JSYS error 2000 via DLion FileTool
To: Taft
cc: , Kierr.pa

Ed,  I was doning a list of [Maxc]<*>SortDict.* and got the following in my Trinity-based FileTool window after a couple minutes:

Remote list of SortDict.*
Opening connection to Maxc ... Done.
Maxc2 Pup FTP Server 1.37 13-Jan-83
Filename error: Undefined JSYS error 2000

For my purposes, you may ignore this.  I thought, though, that you may be interested for Maxc's sake.  /Robert
*start*
01261 00024 US 
Date: Wed, 22 Jun 83 12:13 PDT
From: ornstein.PA
Subject: Maxc Rm. Air Conditioning
To: Taylor, Mitchell
cc: Clark, ornstein, Taft, Lampson

Taft and I have discussed it and we need to boost the air conditioning in the Maxc Room BEFORE the end of the year - if we are to avoid having Dorados we can't run.  We could argue about why this is true, given that before the last go-round we carefully described our needs to Lee and his people and despite this they seem to have cut corners and thus not met the need.  But I think that such argument won't be helpful. 

Ed and I are considering alternative placements (including, for example, Butler's suggestion for a "reduced" Maxc) - but it looks like the main problem could end up being the money to pay for it.  Ed says Lee Anderson indicated roughly $50K to install a new (additional) AC unit.  We need to start looking for that kind of money now.  My take is that until Lee begins to believe that such money is going to be forthcoming, we will only be able to get him marginally interested in the problem.  I believe that we should be prepared to sacrifice one Dorado ($'s), if necessary (and if possible).

Seems to me the first step is to talk to Norb - right?  Who should do it?

S. 
*start*
02905 00024 US 
Date: Mon, 27 Jun 83 14:40 PDT
From: Taft.PA
Subject: Dorado cooling, etc.
To: Ornstein
cc: Taylor, Taft

Here are highlights of the meeting we had today, just so I don't forget anything important.  We can discuss things in more detail after you get back.

Anderson, Beyer, Spencer, Squires, Taft, and Taylor were in attendance.

Last Friday, Conrado Montes circulated a memo containing a recap of Maxc room cooling requirements (not significantly different from my memo of September 1980), and proposing a preliminary plan for providing additional cooling capacity.  The proposal is to raise the floor to increase under-floor volume, and to add a 20-ton air conditioning unit.  Cost: about $80K and 15 work days of downtime.  This requires significant construction work because the interior walls, doors, etc., are built on top of the raised floor.  Lee thinks that with all the other things going on at PARC, it's virtually inconceivable that this could be finished before the first 4th build Dorado arrives on September 30.

Another possibility that was discussed is to remove all the under-floor electrical raceways and provide some alternate means of powering the equipment, thereby eliminating the under-floor obstructions to air flow.  Then add a new 20-ton unit as before.  Lee guessed that this would cost about the same or maybe more, but since it doesn't involve any significant construction work it might be done more quickly.  Even so, Lee is uncertain whether the 7-inch under-floor space is adequate even if free of obstructions.  He is now doing some measurements and calculations to determine this, and promised to report the results within a few days.

Lee also thinks there are some less disruptive interim measures that can be taken to let us get a few more Dorados into the Maxc room, though not nearly adequate to get us all the way to 50.  This would tide us over until major work could be done, such as building a new machine room somewhere (and would also get us into next year's budget -- getting $80K out of this year's budget seems to be a big problem).  (By the way, getting rid of Maxc buys us 4.5 Dorados' worth of cooling.)

This led to a more general discussion about how to house the 38 or so Dorados that will be arriving throughout PARC during the 4th build.  The two new machine rooms have plenty of excess capacity, but are too far away to be any help to CSL or ISL.  The Purple Lab has a little excess capacity right now, but not much.  The space occupied by Ken Beckman until recently could be converted into a machine room if necessary.  With some reshuffling, a few CSL users' Dorados could be located in that area.  Mumble.

The conclusion was that the problem of how to house Dorados needs to be addressed at a PARC-wide level.  In your absence, you were nominated to chair a small committee to consider this (talk to Bob Taylor).

	Ed

*start*
01778 00024 US 
Date: Thu, 30 Jun 83 15:45 PDT
From: Taft.PA
Subject: Maxc Leaf Server
To: VanMelle
cc: Smalltalk80Support, Putz, Taft

---------------------------

Date: Thu, 30 Jun 83 15:16 PDT
From: Putz.pa
Subject: MAXC Leaf Server
To: Taft
cc: Smalltalk80Support, Putz

This is not especially important, since I don't know anyone who really uses files on Maxc from Smalltalk, but I have noticed that the Maxc Leaf server is not exactly compatible with the IFS Leaf server.  In particular:

1)  The user password must be all upper case, or Maxc will not recognize it.

2)  Maxc will not recognize a user name if it ends in ".PA".

The result of these incompatibilities is that Smalltalk cannot communicate with Maxc using Leaf.

------------------------------------------------------------

I don't know how important this is either, or even whether this exhausts the list of problems (for example, isn't the CR vs. CRLF incompatibility a source of trouble?)

Both of these problems are actually shortcomings of the underlying Tenex implementation.  In particular:

  (1) is a bug in one of the JSYSes that deal with logging in or checking passwords or something.  (I've forgotten the details, but I do remember running into the same bug.)
  (2) should be dealt with by changing those JSYSes to handle Grapevine R-Names properly.

I have never had the courage to mess around with this part of Tenex, however.  Both of these shortcomings have been programmed around in PUPSRV.  I suggest the same thing be done in LEAFSV.  In particular:

  (1) can be fixed by always capitalizing passwords before passing them to JSYSes.
  (2) can be fixed by stripping off a ".PA" suffix if it is present.  All Maxc user names are considered to be members of the PA registry.

	Ed

*start*
00885 00024 US 
Date: Wed, 6 Jul 83 14:10 PDT
From: Taft.PA
Subject: Re: More ArpaNet Strangeness
In-reply-to: "Martin.eos's message of Wed, 6 Jul 83 13:14 PDT"
To: Martin.eos
cc: Taft, 1100support.eos

The Arpanet software on Maxc got into a bad state over the weekend that made it not possible to establish terminal connections.  I got it unstuck yesterday.

Nothing has changed recently on Maxc, either hardware or software.  Problems like this one seem to come and go spontaneously.  Certain pairs of hosts often have trouble communicating; this seems to depend on network traffic, timing, or phase of the moon.

I'm afraid I have to disclaim responsibility for the behavior of our Arpanet connection.  The TCP software is not supported and is known to be flakey.  Nobody, including myself, is working on fixing it; so this state of affairs is not likely to improve.

	Ed

*start*
00797 00024 US 
Date: 28 JUL 83 18:38 PDT
From: MASINTER.PA
Subject: a way to get around T20DUMPER problems?
To:   RWeaver
cc:   Taft

8 - *******************************************
Received: from SRI-CSL.ARPA by PARC-MAXC.ARPA; 26 JUL 83 13:07:52 PDT
Date: 25 Jul 83 16:59 PDT
From: DHARE@SRI-CSL.ARPA (Dwight Hare)
Subject: Re: Tops-20 DUMPER for Tenex?
To: MASINTER.PA
In-Reply-To: Your message of 21-Jul-83 2357-PDT

We have a program here called T20DUMPER (on our subsys) which sounds very
much like yours.  It also has problems restoring files because of the
PS: but I have found that a fully specified command will often work.
That might be like:

>restore ps:<*>*.*.*  dsk:<*>*.*;*

You're welcome to try our version of the program, but I have found
it often tempermental.

. . .
*start*
02059 00024 US 
Date: Fri, 29 Jul 83 09:41 PDT
From: ornstein.PA
Subject: Maxc Room Planning
To: Taft
cc: Taylor, ornstein, Clark

Ed,

The question is: how did we fail to adequately redo the Maxc room on the last go-around?  My own impression is that we told Lee how many BTU's we would be putting out and he then provided the necessary air-conditioning to handle it.  Since it is now clear we don't have enough, I have been assuming that they simply goofed on their end of the deal.  I'm anxious to know your impression of what happened.

Yesterday, in the course of discussing plans with Lee, I indicated gentle concern arising from "our" failure to kill the problem last time around.  I was startled to hear Lee claim that "we" never expected, on the last go around, to provide enough cooling for 50 Dorados - that that was only a "futuristic number", not what we were providing for then.  As evidence, he cited your memo - the one that included the calculations and described our needs.  I haven't been able to lay my hands on a copy or find the file and I am most curious to see one as that's not what I remember at all.  I think we were perhaps a tad low on our estimate of a Dorado's power consumption (because all we had to go on at that point was a few early 115 volt machines), but I thought we were definitely laying in plans for 50 of them.   

It is true that we knew it would be some time before Maxc would go away and we would be able actually to house the full 50 machines, but I always understood that we were then and there arranging to pump into the room enough cooling and power to handle the final expected load (50) and that later we might at most have to locally rearrange some of the power when Maxc moved out to accomodate the final Dorados instead.

My guess is that Lee, on his own, decided to save money by only providing for shorter term needs.  This is important (and sensitive) since if it was clearly their failure of execution, it will make it easier to get it fixed than if it was improper planning on our part.

S.
*start*
02660 00024 US 
Date: 20 May 1983 1:01 pm PDT (Friday)
From: ornstein.PA
Subject: Maxc Room Cooling
To: Lee
cc: Overton, Taylor, Taft, ornstein, Sosinski, Yeary

Lee,

I went over the Maxc Room with Charlie Sosinski.  We measured temperatures at
a variety of points, experimented with pulling up floor tiles to increase air-flow
(as we had discussed), etc.

My conclusion is that we need to do something soon that is substantially more
than the minor adjustments Conrado has just done.  Perhaps continued fiddling
will eventually produce results, but so far it hasn't helped enough.  We are
already operating marginally and several things are soon going to make it worse.

	1. Summer students are coming and instead of having several idle
	machines, all machines will be operating full tilt during the heat
	of the day.

	2. We are due to add more machines.

	3. The weather is going to get hotter.

We recently went through a major refurbishing that was supposed to handle
much more than the present load.  It simply isn't coming close and that just has
to be fixed.  I'm no expert and don't want to interfere in the planning, but I
offer the following observations:

1. It seemed, from the calculations at our last meeting, that we are not getting as
much cooling from the present setup as we should expect.

2. At least part of the problem seems to be distribution:

	a) the lower Dorados are generally about 5 degrees cooler than the upper
	ones (75 degree vs. 80 degree input air) and this difference puts us over
	the line for trouble.  Input temp. should be more like 70 degrees.

	b) in addition, there are warmer and cooler areas within the room

	c) the front Maxc room and the IMP room are MUCH cooler - of course
	they contain comparatively little equipment      

3. The pressure of air in the sub-floor plenum doesn't seem excessive so if we
re-piped both units to blow under the floor, perhaps it might help to get the cool
air to where it is needed?

4. The back (hot-air exiting) side of the right hand row of Dorados is particularly
hot and although Conrado tried to open up the ceiling to increase the return
flow, looking up through the grating I can see that much of the flow is blocked
by other pipes etc.  That seems to be one of the worst problems at present -
insufficient return path for that hot air. 

Please let me know what you can do about this before it becomes more of an
emergency.

Severo

P.S.  Mike handed me a sizeable piece of metal cutting that had apparently been
dropped into the back of one of the Dorados while the ceiling was being
modified.  Would you please ask folks to be a bit more careful.  Thanks.  
*start*
03986 00024 US 
Date: Sun, 21 Aug 83 10:53 PDT
From: Taft.PA
Subject: Planning for the demise of Maxc
To: AllPA^, IFSAdministrators^
Reply-to: Taft.PA, RWeaver.PA

We are beginning to plan for the orderly shutdown and eventual decommissioning of our one remaining Maxc system.  The purpose of this message is to give early notice and to collect information about all the uses presently being made of Maxc so that we can determine whether those services will be provided elsewhere or could be terminated.  If you do not use Maxc (aside from Arpanet mail forwarding), you need not read this message.

Why decommission Maxc?  There are several reasons:

-- Maxc is old and tired and is becoming increasingly difficult to maintain.  In particular, the disk drives are wearing out and are nearly impossible to fix due to shortage of spare parts and expertise.

-- The machine room space and air conditioning capacity now consumed by Maxc could more profitably be devoted to additional Dorados.

-- Nearly all the services originally provided by Maxc are now available elsewhere, usually in improved form; for example, electronic mail service by Grapevine, Lisp by Interlisp-D on D-machines, etc.  The residual uses are not sufficient to justify CSL's continuing to operate an obsolete time-sharing system.

We are tentatively planning to shut down Maxc some time early in 1984.  It's unlikely we will be ready earlier than January 1.  You are requested to consider the impact a January 1 shutdown would have on your work, and to begin looking for alternatives to the services now being provided by Maxc.

Here are our intentions with respect to the more important services:

-- File storage.  Obviously, files still needed after the Maxc shutdown will have to be moved to other file servers.  Users will be responsible for arranging to move the contents of personal directories and files-only directories under their control.  Everything left behind will be archived to tape.

-- Arpanet access.  A Cedar implementation of the ARPA TCP/IP protocols and of the mail translation and forwarding functions is now in progress.  This software will be installed on a Dolphin or Dandelion server that will entirely replace Maxc in its role as Arpanet mail gateway.

-- Arpanet terminal access (Telnet) and file transfer (FTP) will be feasible to implement on top of the ARPA TCP/IP software; but there are no immediate plans to implement these.

-- Magnetic tape access.  The tape drives are connected to an independent Alto tape server, which will continue to operate indefinitely.  There presently exist facilities in Alto/Mesa and in Cedar for accessing the tape server.  The tape server protocol is documented and is relatively simple, so accessing tapes from other environments should be straightforward.

-- Tape archives.  We have approximately 600 tapes full of files archived from Maxc during the past 10 years.  We will make some provision for recovering files from the Maxc archive tapes.  However, this recovery procedure is unlikely to be convenient because the Maxc archive directories will no longer be on-line.  Therefore, we request that users examine their archive directories, retrieve any needed files before Maxc is shut down, and transfer them to other file servers.

-- Application programs on Maxc.  In general, users will be responsible for obtaining computing services elsewhere, since CSL does not have the resources to convert application programs.  The only planned exception is the TEX document compiler.  We now have the capability to produce a Cedar version of TEX (by automatic translation from Pascal).  Though there is not a working version of TEX in current Cedar, we expect there to be one in the near future.

If there are any other Maxc services on which you depend and which you can't obtain elsewhere, please bring them to our attention.  While it is unlikely that CSL will continue to provide such services, we may be able to suggest alternatives.

*start*
00419 00024 US 
Date: Sun, 21 Aug 83 12:14 PDT
From: Ritchie.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Ritchie

Ed,
The only facility which I use significantly and which is not scheduled for replacement is Telnet.  Please consider this message a modest request that some planning to provide Telnet be initiated.
Thanks.
Bob

*start*
00464 00024 US 
Date: Sun, 21 Aug 83 14:02 PDT
From: Pavel.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Pavel

I am a heavy user of Maxc for telnetting to other ARPAnet hosts.  I would find it most inconvenient to lose that capability.  I'm told that the Telnet protocols are not difficult to implement; is there no-one with a little extra time to do this?

	Pavel Curtis

*start*
00416 00024 US 
Date: Sun, 21 Aug 83 15:33 PDT
From: Stolfi.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Stolfi

Will there be any convenient mechanism for archiving files on tape (as opposed to retrieving them) after Maxc goes off the air?   Or are we supposed to keep our old-but-not-dead files in remote servers?

jorge


*start*
01086 00024 US 
Date: Sun, 21 Aug 83 16:25 PDT
From: CARD.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Card

I have worries about the maxc shutdown about file archiving.  I have large amounts of experimental data out on those tapes.  There is no way that even a tiny fraction of that data would fit on a file server.  I am willing to use tape (groan) directly [especially if it has a directory] but hope that you gentlemen will at least set up the conventions (since there would be expected to be fairly heavy use from a number of people) and provide more information to plan with.  For example, will someone provide tape mounting service at certain hours? will you continue to provide tapes or must we buy them? is there a conventional density and format?

If MAXC were shut down today, I would lose all statistical analaysis services, because IDL won't run correctly on INTERLISP-D.

Do I understand you correctly, that we will no longer have access to the ARPANET from home terminals?

stu


*start*
00854 00024 US 
Date: 21 Aug 83 19:29:26 PDT (Sunday)
From: Hamilton.ES
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft.PA's message of Sun, 21 Aug 83 10:53 PDT
To: Taft.PA, RWeaver.PA
cc: Hamilton, Newman

	"-- Arpanet terminal access (Telnet) and file
	transfer (FTP) will be feasible to implement
	on top of the ARPA TCP/IP software; but there
	are no immediate plans to implement these."

I'm amazed.  It seems like this would make us real 2nd-class ARPAnet citizens.  It is fairly common for one of the various ARPAnet mailing lists to refer to text files available for FTP.  And I'm not on INFO-MICRO, but I think an increasing amount of public-domain microcomputer software is becoming available this way.  Conversely, we couldn't make files available to the outside.  I think INTERLISP-D is released this way now.

--Bruce
*start*
01672 00024 US 
From: Deutsch.pa
Date: 21-Aug-83 21:35:19 PDT
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: Deutsch

I would like to register strenuous objections to the plan that
Maxc tape archive directories not be kept on-line.  This makes it
almost impossible to retrieve files from the tape archive.
Surely the space required for these directories on a file server would
not be substantial, and it would enable someone to write the equivalent
of the Maxc INTERROGATE/retrieve program with little difficulty.

Interlisp-D on D-machines is NOT a substitute for Lisp on Maxc, because
it isn't accessible from my home terminal!  In fact, NO PARC software
except Grapevine is accessible from home.  I consider this a major
shortcoming of PARC's research program, and the demise of Maxc will be
a major blow to my ability to work productively.

To be specific, I use the following Maxc programs at home: LISP, SRCCOM,
POET, and occasionally SNDMSG when Ernestine is down (since Ernestine's
function, unlike the mailbox function, is not replicated.)  Having
an account at another Arpanet site would not be satisfactory
unless there were either an Arpanet FTP server at PARC that could access
IFS files (unlikely in view of security considerations), or a Telnet/FTP
User accessible from the DLS.

I realize that I am currently in a small minority in wanting to work
at home, but I hope these considerations will lead to a little
consciousness-raising in CSL on the subject.  (SCG is planning a major
push in this area next year, as our conversations on the subject of
DLS's indicated.)

P.
*start*
01025 00024 US 
Date: Mon, 22 Aug 83 07:06 PDT
From: bachrach.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: bachrach

Ed,

My only use of MAXC recently has been for archieving files.

As you may know, the GSLVAX is on the  3 Mbit ethernet as both a file server and will soon be a chat server.  We intend to add a 10Mbit interface within the next six months.  The VAX TU77 magtape is a high performance system and it would be possible to transfer the  MAXC archieve function over onto the GSLVAX if CSL desired.  We currently have, or used to have, an Archieve implementation on the VAX which is essentially equivalent to MAXC service except for the direct interrogation of a status file.  Ron, can you send Ed and myself a copy of the current archieve procedure on the VAX when it is convenient.

Of course when we put the 3 Gbytes of Optimem optical disk on the VAX next year,  most of these "problems" will become less severe.

Bob

*start*
00366 00024 US 
Date: Mon, 22 Aug 83 07:34 PDT
From: BACHRACH.PA
Subject: Archieving
To: Taft
cc:  BACHRACH

Perhaps you could implement the Archieving command under IFS and then let the IFS ship them to whatever the archieving source is, be it the VAX or something else.  That way at the user level, the archieve function would be device independent.

Bob

*start*
00277 00024 US 
Date: Mon, 22 Aug 83 07:35 PDT
From: BACHRACH.PA
Subject: Archieving
To: RWeaver
cc:  Taft,BACHRACH

Ron,

When you get time, can you see if the VAX can read a MAXC Archieve Tape.  If not, lets have UpShaw look at it.  It should not be difficult.

Bob

*start*
00369 00024 US 
Date: 22 Aug 83 09:18:49 PDT (Monday)
From: McElyea.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: McElyea.pa

I just ordered business cards which state "McElyea@PARC-Maxc at the bottom.  
Do you know what the knew name will be so that I might change this?

Shannon
*start*
00716 00024 US 
Date: Mon, 22 Aug 83 09:26 PDT
From: Crowther.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft

I havn't used maxc for anything except playing games for a long time. CSL will certainly be better off when it is gone.  As with any such move, you always lose something - I was able to think of a couple of uses which you hadn't mentioned.

Maxc is occasionally useful as a place to temporarily store files (when something is wrong with the regular file system).

It also provides a quick and dirty way to transfer files to and from a home computer.  Satterthwait had another way to do this, but I doubt it is supported.

 
Will

*start*
00531 00024 US 
Date: Mon, 22 Aug 83 12:47 EDT
From: Axelrod.wbst
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft.PA's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft.PA, RWeaver.PA
cc: WRC-MAXCUsers^, Axelrod

Gents
I'll be sorry to see Telnet and ARPA FTP no longer available to us.  I have to admit that my own need is less than critical, and I understand that everyone is pressed for time.  But I'd sure be happy to see it stay, or at least come back as soon as possible.

Thanks for the warning.
   Art

*start*
00391 00024 US 
Date: 22 Aug 83 10:28:39 PDT (Monday)
From: Halbert.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver

I frequently use incoming and outgoing TELNET on Maxc to look at files on other machines, read mail, etc. Count this as a vote for implementing TELNET and FTP sooner rather than later.

--Dan
*start*
00944 00024 US 
Date: 22 Aug 83 10:41:01 PDT
From: Horning.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Horning

Ed,

Here are the concerns I have:

-- Arpanet terminal access (Telnet) and file transfer (FTP). These are fairly critical to the joint work I do with John Guttag. We FTP Bravo documents and Press files a lot. Access to MIT-XX is not so essential, but will become more important as more of the Larch tools become available (only) in CLU. (Maybe a summer student could bring some of them up in Cedar.)

-- Archiving. You didn't make it clear whether there will be some file server that provides an archive service analogous to MAXC's. I probably have 5-10 times a much stuff on tape as on disk; bringing it all back online doesn't appear to practical, even with disks getting cheaper. And yes, I DO retrieve 5-10 archived files/year.

Jim H.*start*
00412 00024 US 
Date: 22 Aug 83 10:54:53 PDT
From: Nichols.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Nichols

Maxc is the host that the universities in the the University Grant program use to fetch new versions of the software.  There's not a lot of activity these days, but it might cause a few problems.

					David
*start*
01535 00024 US 
Received: from CMU-CS-VLSI.ARPA by PARC-MAXC.ARPA; 22 AUG 83 11:38:11 PDT
Date: Mon, 22 Aug 83 14:33:22 EDT
From: Bob.Sproull@CMU-CS-VLSI.ARPA
To: Taft.pa, RWeaver.pa
Subject: Re: Maxc announcement
Message-ID: <1983.8.22.18.26.31.Bob.Sproull@CMU-CS-VLSI>

Ed,
Well, I guess I expected it would come down to this. My uses of MAXC
are:

1. Reading PARC electronic mail in a PARC machine so that Xerox-related
mail does not transit the network and the various mailer programs.
True, when I read the mail with Telnet, the text transits the network,
but it is my suspicion that mail is more likely to be intercepted than
is terminal traffic.

2. Keeping an archive. The MAXC archive is the finest I have ever had
available, and I have squirreled away a great many things of value (?)
there.  I can, of course, become a tape wizard, using tape machines
here, and I am prepared to do that. However, I mourn the passing of a
very fine service.

3. File transfer from IFS's in the Xerox Internet to CMU so that I can
print Press files; file transfer the reverse direction so that I can
work on Xerox documentation (e.g., Interpress stuff).  I use this method
a GREAT deal; while I realize it may not be exactly according to the
rules of the ARPANET, I don't believe it violates the spirit of the
net.  As I understand it, this scheme will go away, and you do not
plan to implement IP/TCP file transfer to/from the Internet.

Summary: Your scheme is fine, but it would help me a lot if file
transfer were available.

Bob
*start*
01009 00024 US 
Date: Mon, 22 Aug 83 11:30 PDT
From: Subhana.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Subhana

Ed and Ron, I would imagine that I am a fairly typical secretarial user of MAXC.  Let me mention the things I have routinely run through MAXC in the past, and please inform me of ways in which these tasks will be handled in the future.

1.  The CSL Blue and White archives are on <CSLPubs>.  These archives need to be maintained for originals to be printed on Platemaker for reprints of CSL's technical reports.

2.  I use an address sorting hack on <chc> to sort alphabetically and by zip code.

3.  I use Tex, especially for Greg Nelson's papers.

4.  (I think there may be other more serious uses but they don't occur to me right away)  I also, especially in the evening when I can get into the older form, play adventure on <games>.

When I think of other serious uses, I'll let you know.

Subhana

*start*
00367 00024 US 
Date: 22 Aug. 1983 11:40 am PDT (Monday)
From: mannes.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: mannes

I use MAXC frequently to make address labels.  This program allows me to
alphabetize the names.  What is going to happen to this program?

Fumiko (x4101)

*start*
00395 00024 US 
Date: 22 Aug 83 12:16:10 PDT (Monday)
From: Daniels.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: Daniels

Well, since I use MAXC mainly for archiveal these days, I think I'll update the access code to run in the XDE.  Where can I find it?  I'd prefer the Alto/Mesa version.

			-- Andy. --
*start*
01048 00024 US 
Date: Mon, 22 Aug 83 12:47 PDT
From: McCall.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: McCall

As a part-time student at Stanford, I have benefitted greatly from the telnet service available on MAXC.  Having had a relatively high-bandwidth connection to Stanford's SCORE computer has allowed me to spend more time at PARC and still attend to my responsibilities at Stanford.  DLS is almost prohibitively slow.  I have made a similar use of Maxc's FTP facility.  I feel it would be a great loss to eliminate this high-bandwidth path into and out of PARC.  Is there a substitute?

Will we still be able to archive files easily?

As far as "any other Maxc services on which you depend" is concerned, I found it very convenient to have access to some Pascal and SNOBOL around here (someone else in my class brought the compiler and interpreter over from Stanford)  Are there any other ways I could get access to such facilities?

Thanks,
Kim

*start*
01267 00024 US 
Date: 22 Aug 83 12:52:56 PDT (Monday)
From: Newman.ES
Subject: Re: Planning for the demise of Maxc
In-reply-to: Hamilton's message of 21 Aug 83 19:29:10 PDT (Sunday)
To: Taft.PA, RWeaver.PA, Hamilton
cc: Newman

Only one aspect of this bothers me:

"Arpanet terminal access (Telnet) and file transfer (FTP) will be feasible to implement on top of the ARPA TCP/IP software; but there are no immediate plans to implement these."

Without FTP access, there is NO way to transfer files from the Arpanet to the Xerox Internet, or vice versa.  We will have no way to examine mailing list archives or large remote files that are infeasible to mail through the Arpanet.  Similarly, a Xerox user will no longer be able to make such a large file or archive available to anyone else on the Arpanet.

Without TELNET access, we will be cut off from all software and applications that may be runnable on the Arpanet.  We will no longer be able to run application programs on other Arpanet machines on which we may have accounts (MIT-*, SAIL, SCORE, CMU, Rand, etc.).  We will not even be able to access the Arpanet NIC database, or read Arpanet RFC's.

I urge you not to decomission Maxc until replacement Arpanet Telnet and FTP service is available.

/Ron
*start*
00354 00024 US 
Date: 22 Aug 83 12:54:42 PDT (Monday)
From: Newman.ES
Subject: Re: Planning for the demise of Maxc
In-reply-to: Hamilton's message of 21 Aug 83 19:29:10 PDT (Sunday)
To: Taft.PA, RWeaver.PA, Hamilton
cc: Newman

I believe there may be people other than AllPA^ and IFSAdministrators^ who may have an interest in this issue.

/Ron

*start*
01453 00024 US 
Date: Mon, 22 Aug 83 13:19 PDT
From: VanLehn.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: VanLehn

Folks --
I trade data with other psychologist using tapes.  Will there be a way to take my data files out of archive, put them temporarily on a file server, and make a tape?  The data files are unformated ascii text files.  

The decomissioning of archiving seems outrageous to me.  Perhaps CSL should not have to bear the expense of archiving all of Parc's files, but it is dangerous and expensive not to have some kind of archiving.  It is inconceivable to go without archiving.   The file servers would clog up in a month.  

Moreover, once an archive facility is established, assuming it is, it would waste man-years of Parc's effort to force them to "examine their archive directories, retrieve any needed files before Maxc is shut down, and transfer them to other file servers."  Can you remember what's in a file that's two years old given only the file name?  I sure can't.  It would waste tons of my time to unarchive all the likely files, read them, and decide which to save.  If everyone did that (and what other choice do they have, if the old archive isn't continued), it would clog maxc,  wear Ron out unarchiving useless files, and waste many people's time.  We should save the whole archive, even if it is 600 tapes.  

-- Kurt  

*start*
02044 00024 US 
Date: Mon, 22 Aug 83 13:33 PDT
From: Taft.PA
Subject: Arpanet FTP & Telnet access
To: Taylor, Fiala, Ornstein, Schroeder, MBrown, Lampson
cc: RWeaver, Taft

First of all, I hope you people don't mind my using you as an informal review committee for proposals relating to the Maxc shutdown.

Ron and I have received quite a lot of responses already.  In a few days I will summarize them and compose replies to the most frequently expressed comments.

Not surprisingly, the most controversial issue was that of FTP and Telnet access to the Arpanet, which I said we are not signing up to implement.  There are a lot of people who say that this capability is important to them.  Connections originated from within Xerox and connections originated outside both seem to be important.

Assuming the successful outcome of our Cedar TCP/IP implementation, building Telnet and FTP on top is technically straightforward.  The reasons I did not want to commit to doing this are:

  (1) While straightforward, it's still a lot of work, especially for FTP which is a fairly elaborate and complicated protocol.

  (2) There are all sorts of security and access control ramifications that would have to be carefully thought out.  The needed mechanisms might be as much work to implement as the basic Telnet and FTP protocols.

There is another alternative that has just recently come to my attention.  There is a company called Compion (formerly Digital Technology Inc.) which sells a software package implementing the complete suite of ARPA protocols for the VAX running VMS.  If we could get GSL to agree to install this on their VAX and to permit people to use the VAX to obtain the Telnet and FTP service they now get from Maxc, this would solve our problem.

Prices: software, $15K; software maintenance, $4K; hardware to connect VAX to Imp, $5-10K (this is just a guess).
		
I don't see what's in this for GSL, so I doubt they'll be very interested.  But it does seem like the easiest approach if it's politically feasible.

	Ed

*start*
02504 00024 US 
Date: 22 Aug 83 13:35:10 PDT (Monday)
From: Woods.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: Woods

I would feel the lack of Telnet, since I frequently read my mail from home by dialing into SAIL (which knows how to run my display) and crossing through Maxc to Ernestine.  Likewise, I often find I want to get hold of someone at Stanford on short notice, or take a look at a distribution list or other data file at Stanford, and so Chat from my Dandelion to Maxc and Telnet to SAIL to poke around.  Both of these uses can be handled using the autodialers here and at SAIL, but you should note that the increased use will result in higher phone charges.  If there are enough people in similar straits, the increase in charges might be severe enough to warrant allocating the manpower to implementing Telnet.

The lack of FTP, though less severe because I use it less often, is much harder to circumvent.  I've found in the past that the DLS, at either 300 or 1200 baud, drops a lot of characters -- often entire lines -- when connected to SAIL.  Thus, dialing across and typing a file and capturing the session transcript is not really a feasible alternative (not to mention that it is quite slow).  Furthermore, some sites (notably SCORE) found that network mail was being used as a surrogate FTP, which bogged down the mailer; as a result, those sites now refuse to handle mail beyond a certain size, and there are threats of more severe repercussions if mail-cum-FTP continues.

FTP definitely has its uses, since one of the big advantages of the Arpanet is that, having located a bit of useful research somewhere, you can fetch it over and use it without having to reconstruct it.  Just recently, I FTP'ed the high-speed text-search program I wrote at SAIL and converted it to Mesa; it will replace the official Find.bcd as of the next Mesa release.  Again, I am not in a position to analyse the impact, but I feel you should give further consideration to the question of when to implement FTP.

Finally, there is the impact of MSG users forced to start using Lily.  Lily is obviously inferior in most ways, but for the most part this is mere inconvenience.  One such inconvenience that might have been overlooked, and might be feasible to fix, is that Lily has no way at present of handling private distribution lists.  Perhaps it can be made to handle distribution files on IFS's?

	-- Don.

*start*
01058 00024 US 
Date: Mon, 22 Aug 83 14:01 PDT
From: Putz.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Putz, SCG^
Reply-To: Putz.pa

SCG uses Maxc for its tape archive facility.  Periodically, we copy Smalltalk system images, etc. to [Maxc]<Smalltalk> for archival.  This is very useful, since it allows us to delete old unused files from our IFS without worrying about possibly losing important information forever.

Without even the inconvenient archival facility of Maxc, the alternatives are filling our IFS with old unused files, or more likely, deleting those files forever.

I strongly believe that the having project history information and data stored permanently (on tape, laser disk, etc.) is very valuable.  Often it is impossible to determine until much later what information should have been saved.

It will be very unfortunate to have no usable tape archival facility.  An archive-server associated with the tape-server would be very nice.

-- Steve

*start*
00376 00024 US 
Date: 22 Aug 83 14:05:14 PDT (Monday)
From: Zdybel.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: Zdybel.PA

I need occasional telnet and ftp access to the ARPANet.
Losing these capabilities poses substantial problems, closes
off important avenues of collaboration.

Frank
*start*
01190 00024 US 
Date: 22 Aug 83 14:45 PDT
From: auguste.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft.PA's message of Sun, 21 Aug 83 10:53 PDT
To: Taft.PA, RWeaver.PA
cc: auguste


ed,

when i am at parc, i use maxc for telnet and ftp almost daily.
  
your note mentioned that there are no immediate plans to implement ftp and telnet; will there be any other way to ftp files across the arpanet?  i cannot run existing scribe files here, so i run them through at another site and ftp the press files around.   i also ftp files which i share with other people; we edit them in turn and store them in common directories on the net.

the telnet facility is the most important to me, however, because i frequently need to send and receive mail on a machine at cmu which is not directly on the arpanet; it is accessible through cmu's decnet connection, which is up only 2-4 hours per day -- forwarding through such a bottleneck is virtually impossible.

is it possible that we could establish a permanent (hardwired?) connection with another (nearby) arpanet site for these services?  


-- donna 

p.s. - i also use emacs on maxc, but i can get along without it.



*start*
01668 00024 US 
Date: Mon, 22 Aug 83 15:01 PDT
From: Kaehler.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Kaehler, Lavandel, Carothers, SCG^

Archiving is the service I will miss the most when MAXC retires.  I believe that archiving is very important, due to the facts about human nature.

We need a semi-infinite, low cost place to easily put old files.  The act of archiving must be easy, so people do not have to think twice about doing it. 

Archives pay themselves back many times over when something is really needed (witness the source code for Laurel 7.0, etc.).  The projects going on at PARC are historic, and I believe that it is important to preserve the machine readable record of what happened.  For that matter, archived source code and memos will be extremely important if Xerox is ever involved in a software related lawsuit.

If a person must know a lot about Cedar and the tape server, or must go to the MAXC room and load a tape to archive something, no one will ever do it.

	Ted.

P.S.

What we need is a simple way to archive files from IFS servers.  Suppose that a person could archive a file from a file server by sending Ron Weaver a message.  He would batch the messages, copy the file names to a file, submit the file to a program, and run the tape server.  The program would write tape, delete the files from the file servers and send confirming messages.

P.P.S.

For those of us that have been archiving for nine years or so, it is important to be able to read the archive directories.  Are there any programs outside of MAXC which can do this?

*start*
00714 00024 US 
Date: 22 Aug 83 15:52:17 PDT (Monday)
From: Newman.ES
Subject: Re: Planning for the demise of Maxc
In-reply-to: Woods.PA's message of 22 Aug 83 14:38:52 PDT (Monday)
To: Woods.PA
cc: Taft.pa, RWeaver.pa, Hamilton, Newman

Simulating FTP by "dialing across and typing a file and capturing the session transcript" is not only infeasible, it is often impossible.  Many sites allow a remote FTP login of ("Anonymous", any password) but do not allow such a Telnet login.

Among these sites are SRI-NIC, repository of RFCs and IENs, and OFFICE-3, which contains the famous shared file "<Almsa>Interest-Groups.txt", a frequently-updated list of all Arpanet mailing lists known to humankind.

/Ron
*start*
00755 00024 US 
Date: 22 AUG 83 16:07 PDT
From: GIFFORD.PA
Subject: Re: Planning for the demise of Maxc
To:   Taft, RWeaver
cc:   GIFFORD

In response to the message sent  Sun, 21 Aug 83 10:53 PDT from  Taft.PA, RWeaver.PA

Hi Ed. Us folks out here in Arpanet land use maxc to read our parc
mail and to send mail.  I suspect that CSL folk on the road would
also like to be able to read their mail.  I suppose a 
TCP Telnet <-> Chat server would be the best solution, allowing
people in Arpa land access to mail and file server terminal based
functions, and would also allow people at parc to to talk to
arpa hosts.  I presume that Ernestiene may also have to be
beefed up somewhat.

Hope you are well.  Stop by if you are out here!

Cheers,

Dave
*start*
00583 00024 US 
Received: from RAND-UNIX.ARPA by PARC-MAXC.ARPA; 22 AUG 83 17:28:09 PDT
Date: Mon, 22 Aug 83 17:15 PDT
To: Taft.PA, RWeaver.PA
cc: guyton@rand-unix.ARPA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Your message of Sun, 21 Aug 83 10:53 PDT.
From: guyton@rand-unix.ARPA

Hi,

Just a note to remind you that Maxc is used by the Pasadena
folks for Interlisp-D distribution to Arpanet people.  I sure
would hate to have to go back to mag-tape.

-- Jim

p.s. Your msg was forwarded to me by a friend who still is
at Xerox and knows we have 5 dolphins.
*start*
00398 00024 US 
Date: 22 Aug 83 18:23:05 PDT (Monday)
From: Hamilton.ES
Subject: Re: Comments about demise of Maxc
In-reply-to: Taft.PA's message of Mon, 22 Aug 83 18:01 PDT
To: RWeaver.PA, Taft.PA
cc: Hamilton, Newman

p.s. as long as MAXC is going to disappear, what say we change our site name to something a little less obscure (and closer to the truth) like just plain XEROX.

--Bruce
*start*
01487 00024 US 
Date: 22 Aug 83 21:38:44 PDT
From: Guibas.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Guibas

Both Telnet and FTP access to the Arpanet is quite important for several members of the algorithms group, for these reasons:

1. All of us occasionally (say around once a month) need to use MACSYMA or some equivalent symbolic manipulation system. Access to such a system is an important, and a times indispensible, tool for the research that we do.

2. Many of us work in collaboration with people elsewhere on the arpanet, on joint papers and other projects. While a message facility will at least allow us to transfer the characters of a file back and forth, it requires the active cooperation of both sides each time and has no substitute for the ability to browse through your co-author's directory for relevant files. A number of standard compilers on maxc (Fortran, Pascal, Sail) give us at least some measure of program compatibility with the outside world.

3. If we are to maintain TEX locally, we must be able to ftp new versions of the sources from Stanford. The same will be true of other Pascal->Mesa programs whose sources are updated elsewhere.

4. Browsing on bulletin-boards elsewhere on the Arpanet is useful as a way to keep in touch with those places. And the ability to have a two way conversation over a telnet connection is always fun and at times useful.

	Leo
*start*
00908 00024 US 
Date: 23 Aug 83 10:22:08 PDT (Tuesday)
From: Danielson.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: Danielson

My main use of the Arpanet is mail and user FTP. Since mail access is being addressed, I will deal only with user FTP and simply give two examples of use during the past several months:

1.  Access to Arpanet RFCs to keep up on current Arpa protocols.

2.  Access to CPM program archives. This proved very useful when we were investigating the different types of "asynchronous FTP" packages available for micros.  One of these will probably be implemented to allow simple FTP access via the ITS (Interactive Terminal Service).  Without access to the Arpanet via FTP, our search for information about these types of protocols would have been much more difficult.

Thanks for listening,

Bill 
*start*
00387 00024 US 
Date: 23 Aug 83 10:58:04 PDT (Tuesday)
From: Israel.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver

Do you have a notion of what recovering files from the Maxc archive tapes will be like?  Would it help if each user plans ahead by doing an 

	@interROGATE *.*;* 

and saving the results?
*start*
01014 00024 US 
Date: Tue, 23 Aug 83 11:13 PDT
From: BACHRACH.PA
Subject: FYI
To: Boggs,taft
cc: JWhite

FYI
---------------------------

Date: Tue, 23 Aug 83 10:31 PDT
From: BKorbholz.ES
Subject: DEI Release 4.01A
To: DEI-Interest^.es, DEI-Users^.es
cc: Charlie Sie (A2-22) <ESMail>
Reply-To: BKorbholz.ES

Version 4.01A of the VAX/VMS DEI software is released and available in user account DEIREL on the TAOS file server.  This version contains support for a Chat Service, a Chat Client, and an Echo Client.

All System Administrators of VAX/VMS systems running DEI should OPEn a connection to TAOS, LOGon to DEIREL (password DEIREL), RETrieve README.TXT and REL401.TXT, read them, and follow the directions.

Since version 4.01 is a point (partial) release, you must have version 4.00 of DEI installed in order to upgrade to 4.01.

If your DEI VAX cannot access TAOS, you may send me a tape and I'll copy the release onto it for you.

Bill

------------------------------------------------------------

*start*
00757 00024 US 
Date: 23 Aug 83 14:07:11 PDT (Tuesday)
From: Rosenberg.PA
Subject: Re: Maxc's demise
To: Taft.PA, RWeaver.PA
cc: Rosenberg

I find the planned demise of Maxc understandable but distressing, for two reasons:

1.  Without an ARPA host for TELNET and FTP, neither I nor anyone else at Xerox will be full members of the ARPA community.  A (possible) Cedar implementation will not help non-Cedar users.

2.  Without a useful archive retrieval system, I and everyone else at Xerox will be forced to increase disk space usage considerably.

A possible solution might be to replace Maxc with a VAX 11/750 running Unix to handle both the ARPAnet connections and tape archiving, since the software already exists for those functions.

Jarrett
*start*
01640 00024 US 
Date: Tue, 23 Aug 83 16:18 PDT
From: Taft.PA
Subject: Using VAX to replace Maxc services
To: Taylor, Fiala, Ornstein, Schroeder, MBrown, Lampson
cc: RWeaver, Taft

I just had a chat with Bob Bachrach.  He seems very receptive of the idea that the VAX be used to replace certain services now provided by Maxc.  Specifically:

(1) We purchase the hardware and software required to connect the VAX to the Arpanet, and use it to provide ARPA FTP and Telnet access.  See my previous message.

(2) We use the VAX's tape archive system as a replacement for the one used on Maxc.  This does not eliminate the need for us to write a program for reading the old Maxc archive tapes.  But many people have pointed out the need to provide a continuing service for archiving files to tape (comments about this ranked second only to comments about FTP and Telnet access).

I don't yet know enough to determine whether these proposals are technically sound.  However, I think that before I start digging to any greater depth, some preliminary work needs to be done along the following lines:

  (1) Decide whether this is a feasible approach from an organizational and political point of view.

  (2) Come to some reasonably formal understanding with GSL about using their VAX to provide PARC-wide services.

  (3) Determine who is going to pay for the hardware and software that is required.

  (4) Determine how any required technical expertise is to be obtained.  (GSL has no in-house VAX wizards, but instead depends on an outside consultant.)

  (5) Decide who is to represent CSL in these matters -- me or someone else?

	Ed

*start*
00788 00024 US 
Date: Tue, 23 Aug 83 16:44 PDT
From: Taft.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "McElyea's message of 22 Aug 83 09:18:49 PDT (Monday)"
To: McElyea
cc: Taft, RWeaver

I am in the process of getting our Arpanet site's name changed from PARC-MAXC to Xerox; however, I expect it will be a long time before this change propagates widely enough to be dependable.

Frankly, I would be inclined not to put your Arpanet address on business cards, for two reasons:

  (1) There is a possibility that someone will think you use the Arpanet for all sorts of Xerox business not related to ARPA-sponsored activities and get all upset.

  (2) Your Arpanet address is probably of interest to only a tiny fraction of the people to whom you give cards.

	Ed

*start*
00527 00024 US 
Date: Tue, 23 Aug 83 18:44 PDT
From: ornstein.PA
Subject: Re: Using VAX to replace Maxc services
In-reply-to: "Taft's message of Tue, 23 Aug 83 16:18 PDT"
To: Taft
cc: Taylor, Fiala, Ornstein, Schroeder, MBrown, Lampson, RWeaver

I think it unwise to put ourselves in a position of depending on any non-CSL organization for providing life-support facilities.  That means we should control both any hardware and any software we really depend on.  Other than this principal, I have no objections.

S.

 

*start*
00851 00024 US 
Date: Wed, 24 Aug 83 10:37 PDT
From: chiang.PA
Subject: The Demise of MAXC
To: Taft, RWeaver, IFSAdministrators^, Berkovitz, Biegelsen, Dahlquist, DMoyer, Tuan, Zarzycki
cc: Chiang
Reply-To: chiang.PA

For those of us still using ICARUS for circuit design (because of a lack of D machines and color monitors required by Chipmonk), there are some tape writing utility programs on MAXC which have to be maintained. These are PGT for generating IC masks on MANN 3000 machines, EBCDIC for making printed circuit board masks on the Gerber plotter, and the SAIL program needed for the execution of the two above.

I would like to know how we can transcribe and maintain these programs on another file server. Also, the people using Chipmonk must have a tape writing program of their own, what are they planning to do with it?

Anne

*start*
01315 00024 US 
Date: Wed, 24 Aug 83 06:13 PDT
From: BACHRACH.PA
Subject: GSLVAX Account for Ed Taft
To: RWeaver
cc: Taft, Hagstrom,BACHRACH

Ron,

I spoke with Ed Taft yesterday about use of the VAX for some of the transaction functions now provided by MAXC.  I have given Ed permission to start to experiment with transfering or creating these activities on the VAX since it is difficult to project what the impact will be on the general throughput.  Jim Boyce is away for several weeks, but I will discuss this with him when he returns and we will decide on how to allocate the transaction accounts over the disk system. We will also asses what augmentation is needed to account for both the current increase in demand and this new usage.

Would you create a general user account for Ed and provide whatever liason is needed.  (If you haven't created accounts, would you have Kuo-Foo show you how so you can provide this function to the second floor in the future similar to how you are handling MAXC.)  If it turns out Ed needs operator privaleges, would you create an account called <CSLOP> with the same attributes as <GSLOP>.

I mentioned to Ed that Bob Upshaw <BobUp> is available for consultation on any of the things he wants to consider doing.  Jeff Gallup is the backup resource.

Bob Bachrach

*start*
00522 00024 US 
Date: 24 Aug 83 15:16:20 PDT
From: RWeaver.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "bachrach's message of Mon, 22 Aug 83 07:06 PDT"
To: bachrach
cc: Taft, RWeaver

Bob,

	I'd be happy to send both you and Ed a copy of the VAX archive procedure, and I will 
do so, but you should be aware that the last time I tried it (which was just before I left for
the Philippines) it did not work.  It was the first time I tried it since the implementation of
VAX/VMS Version 3.

		Ron...
*start*
00309 00024 US 
Date: Wed, 24 Aug 83 16:00 PDT
From: BACHRACH.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "RWeaver's message of 24 Aug 83 15:16:20 PDT"
To: RWeaver
cc: bachrach, Taft

Ron,

I'll get Bob Upshaw to check things out.  Do we do a double recording with this system?

Bob

*start*
00588 00024 US 
Date: 25 Aug 83  8:36:39 PDT
From: RWeaver.pa
Subject: Re: Using VAX to replace Maxc services
In-reply-to: "ornstein's message of Tue, 23 Aug 83 18:44 PDT"
To: ornstein
cc: Taft, Taylor, Fiala, Schroeder, MBrown, Lampson, RWeaver

In view of my observed lack of GSL VAX software expertise inhouse, and the inherently
slow response from the consulting expert, I wouild tend to agree strongly with Severo's
comment.  I have found that even the RDC in Boulder is less than satisfactory as opposed
to having a real knowledgeable person inhouse (as Jim Bratnober was).
*start*
02039 00024 US 
Date: Thu, 25 Aug 83 09:06 PDT
From: BACHRACH.PA
Subject: VAX and PDP11 Ethernet Hardware and VAX Communications Software
To: Hagstrom
cc: Taft, Mannes

Stig,

Can we have OSL buy a couple of things for the VAX.  They are now one of our biggest users and haven't contributed a dime.

One addition would be the 10 Mbit ethernet system from Interlan.  Another is a communications software package Ed Taft would like to add to the VAX as part of the process of maintaining for PARC some important services that are dependent upon MAXC.   In connection with this, we should add another megabyte of memory to VAX.

Bob

---------------------------

Date: Thu, 25 Aug 83 08:15 PDT
From: BKorbholz.ES
Subject: 10-Mb Ethernet Hardware
To: DEI-Interest^.es, DEI-Users^.es
Reply-To: BKorbholz.ES

Here is the long-awaited information regarding ordering of hardware for support of DEI on 10-Megabit Ethernet.

You must place your order with:
	Interlan, Inc.
	3 Lyberty Way
	Westford, Massachusetts 01886
	Attn:  Valeri Tirpak

Valeri is handling the Xerox account.  You can reach her at (617) 692-3900 ext. 218.  I have arranged for a 1-year quantity discount agreement.  The prices are as follows:

Number		Description				Unit Price

BD-NI1010A		Controller Board			$2393
SL-NS2030-U		Device Driver Software License	    43
AC-NM10-10	Flat Cable with Connectors	    55

UN-NT10		Transceiver				   250
IK-NT10		Transceiver Installation Kit	   275

Each DEI machine (VAX or PDP-11) will need 1 each of the first 3 items, (controller board, software license, and flat cable).  You can use any transceiver and drop cable, i.e. you don't have to buy Interlan's.  Thus the total price (before tax) for upgrading a DEI machine would be $2491.  Depending on your requirements, a spare controller board might not be a bad idea.

If you have any questions regarding the hardware, contact Valeri or me.

As for our software, it should be available within a week or so.

Bill

------------------------------------------------------------

*start*
00318 00024 US 
Date: 25-Aug-83 10:29:29 PDT (Thursday)
From: Ladner.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft.PA's message of Sun, 21 Aug 83 10:53 PDT
To: Taft.PA, RWeaver.PA

I occasionally use the IDL program and library.  Where would this system end up in the new scheme of things?
*start*
01362 00024 US 
Date: 25 Aug 83 17:25:24 PDT
From: Swinehart.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Swinehart

Here are some uses I make of Maxc:

1. EMACS or TECO from home.  I can do significant text editing this way, actually.  For replacement, I need a reasonable editor and a way to get to my Dorado's user exec, including a way to apply power to the Dorado if it's off, and boot it (Rollback? remote log-in?) if it gets wedged.

2. University grant file distribution.  This is the only system that is reachable by Arpa types, at present.  An ARPA FTP with the right internal addressing structure and distribution list control will fix this one.

3. Tape archives.  I claim we need a really reasonable and convenient set of facilities, probably Alpine-based, before we should give up Maxc.  I still use Maxc for file archive, even given the hassle of copying files from IFS's (often renaming to deal with subdirectories) to do it.  We should consider saving all of the present archive directories somewhere, too, so that retrieval from old Maxc tapes will not be so bad.  I think it will place a burden on people to try to predict in advance which of they're archived files they're going to want.

4. <GAMES>WUMPUS.  But I guess we can't have everything.

Dan
*start*
00918 00024 US 
Date: 29 Aug 83 11:02:18 PDT
From: swinehart.pa
Subject: Re: Clean up Indigo directories
In-reply-to: "Taft's message of Mon, 29 Aug 83 09:56 PDT"
To: RWeaver, Taft
cc: swinehart

I've missed truly reasonable (non-automatic) archiving for years.  I really like to keep my on-line storage low -- primarily to keep the directories small.  Even a reasonably inconvenient archiving system that preserved subdirectories would make it more likely that people could clean up large project directories.  Without it, there is a strong tendency to want to use IFS as an archival storage medium.  I know of no good alternative.

Let's make sure we use up the next available summer student type to work on this kind of thing, if we can't find any other way to do it.  Even if Alpine succeeds in taking up the load pretty soon, I suspect an IFS archival scheme would remain valuable for some time to come.
 *start*
01179 00024 US 
Date: Mon, 29 Aug 83 11:54 PDT
From: Fikes.pa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Fikes

I was out of town last week and just read your message regarding the planned demise of Maxc.  I have two types of reactions:  one as a personal Maxc user and second as an IFS administrator.

As a personal Maxc user, I regularly use Maxc via DLS from my terminal at home.  The primary use is writing and editing documents (via SOS), although I also use LISP from home.  I also regularly use the "calendar" program on Maxc (from my D machine at work and from home) to maintain my daily calendar.  It is very crude but has sufficient functionality and ease of access to make it worthwhile for me.  So, losing Maxc will significantly effect the computing facilities that I regularly use.

As an IFS administrator, Maxc plays a vital role as PARC's archive server.  What plans to you have for providing or coordinating the development of a replacement archive facility?  Certainly there is a vital need for such facilities and I am not aware of any current alternatives.

richard 

*start*
04304 00024 US 
Date: 29 Aug. 1983 1:20 pm PDT (Monday)
From: Winograd.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: Winograd, BrianSmith

The message about MAXC was long-expected, but still raises a lot of questions. 
Before going into details, I should acknowledge that I am a somewhat special
case, since I do somewhat equal amounts of work at PARC and at Stanford, so I'm
neither an occasional user of PARC systems, nor a fully dedicated one. 
However, I suspect a lot of people are in somewhat similar situations, and there
will be more through things like the collaboration with the new CSLI at
Stanford.  I would hate to see a necessary technical change end up having the
effect of making PARC even more isolated from the rest of the academic
computer science community.  I would encourage the creation of whatever new
facilities are necessary to maintain and strengthen the ties.

My current uses of MAXC, which are not easily shiftable are the following:

FTP and TELNET:  I often transfer files back and forth to Stanford and other
sites.  Your message says: "Arpanet terminal access (Telnet) and file transfer
(FTP) will be feasible to implement on top of the ARPA TCP/IP software; but
there are no immediate plans to implement these."  I can't imagine that I am the
only one for whom the lack of an FTP to the rest of the world would be a
tremendous hindrance to my own work and my communication with others. 
Telnet is only slightly less critical.  I use it often in both directions (especially
for logging in to other ARPANET systems while working at PARC).  I really
don't think it makes sense to have any interim period without MAXC and
without a full implementation of these services.

Remote mail reading:  I often log in from home or from Stanford to read my mail
here.  In order to do this, I have kept my Mailbox on MAXC.  Presumably I
could come in over the DLS or ARPANET (assuming TELNET and the
appropriate CHAT connectivity) and log in to a mail server (is that possible?) but
the mail reading programs available there are pretty primitive.  There must be
others who at least log in from home.

Archiving:  You discuss the problem of getting back old archived files, but what
about archiving new ones?  I currently have files on IVY that could well be
archived, but haven't been because of the difficulties (e.g. file name format
incompatabilities).  Without some kind of easily accessible archive facilities, we
will just need to keep buying disc drives.   As an example of my needs, I have
the source files for an entire book which are archived and which will not be
needed for a few years, but which will then have to be retrievable to work on a
second edition.  I currently do not have anywhere near enough room on IFSs (in
spite of very large allocations) to store all of the things I have archived that I
wouldn't want to lose.  I suggest that in addition to providing a new archive
facility, you offer a one time direct archive-to-archive transfer for files people
select from what is currently in the MAXC archives.  Of course, people can be
asked to use their own private tape libraries instead of a common archive
facility, but that seems like a step backwards, and will cetainly encourage the
overcrowding of the file servers.

TEX:  A Cedar TEX will be fine, if it can be installed as a server.  Since I (and
many others) have machines (e.g., ALTO II) that do not run Cedar or do not
have it installed, it would be a large inconvenience to have to go make use of a
CSL Pool Dorado if TEXing is part of the regular cycle of document prepration
(edit, TEX, look at the result, iterate..).  It would also presumably add to the
demand by outsiders on CSL Cedar Dorados.

HARDCOPY:  The HARDCOPY program on MAXC is the only one I know of that
takes a BRAVO file and produces an acceptable ASCII substitute.  Is there
something else that runs on an ALTO or could be installed as a server?.  I know
that for part of the world, BRAVO will be replaced by CEDAR-based systems,
but that part of the world is not the full MAXC user set.  

I may come up with more later, but that is the major part.  Thanks for your
efforts to keep the system as useful and convenient as it has been.

--t

*start*
01435 00024 US 
Date: Mon, 29 Aug 83 19:53 PDT
From: AHenderson.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: AHenderson

Ed:

Just got back from vacation and some conferences. Hence the delayed reaction to your message.

-- Arpanet terminal access (Telnet): When travelling to non-Xerox sites, I use MAXC to get to Ernestine to look at mail. Removing this capability will be inconvenient. What will replace it?

-- Arpanet file transfer (FTP): As a member of the AI community, I find it useful to exchange files with ArpaNet folk. Again, removing this will be inconvenient and will have the effect of further cutting Xerox off from the real world. Any suggestions? 

-- Tape archives: Do I read this correctly? No further archiving? And inconvenient retrieval of files already archived? And the only solution: to use up more of the overloaded IFS space for seldom-used, but important files? If so, then PLEASE THINK AGAIN. This would be QUITE unacceptable. But come to think of it, there is no archiving ability in the NS world, either, is there? By now, you would think we would have learned that safe reliable storage of old records is a crucial part of the life-cycle of information. Xerox ought to be thinking hard about how to support it. How about an archive server, for everyone's good? As I say, PLEASE THINK AGAIN.

Thanks,

Austin



*start*
00731 00024 US 
Date:  5 Sep 83 14:07:46 PDT
From: Horning.pa
Subject: MAXC/John Guttag
To: Taft
cc: Horning

Ed,

Is there any advantage to pursuing this possibility?

Jim H.

-------------------------------------
Received: from MIT-XX.ARPA by PARC-MAXC.ARPA;  3 SEP 83 15:24:31 PDT
Date: 3 Sep 83 09:39 EDT
From: John Guttag <GUTTAG@MIT-XX.ARPA>
Subject: maxc
To: horning.PA

Jim,

     I can certainly understand why it is a good idea to retire
Maxc.  I wonder if the solution to our problems might involve
finding a way for me to connect to one of the internal Xerox
nets.  I do have an RS232 interface on my alto, if that is any
help at all.

John
-------

------------------------------------------------------------
*start*
00602 00024 US 
Date: Mon, 5 Sep 83 14:24 PDT
From: Taft.PA
Subject: Re: MAXC/John Guttag
In-reply-to: "Your message of 5 Sep 83 14:07:46 PDT"
To: Horning
cc: Taft

Unfortunately, to my knowledge there is not a dial-in port in the Boston area; the closest is Webster, N.Y.

Be assured that I'm not seriously contemplating decommissioning Maxc without finding some alternate path for FTP and Telnet traffic.  My implied threat was intended mainly to flush out all the affected users and perhaps to identify some group of people who might be talked into helping to provide the replacement.

	Ed

*start*
01225 00024 US 
Date: Tue, 6 Sep 83 15:47 PDT
From: PMartin.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft, RWeaver
cc: Pugh, PMartin

The Multi Project Chip (MPC) VLSI Implementation Service is a MAXC user in two ways, the first a good deal more than the second:
 
1)Maxc Mailbox - MPCHIP.pa. According to Alan Bell, the former MPC czar, the mailbox remained on MAXC for three reasons:
a)It enabled previewing the messages
b)It was an independent backup, if the MPC message parsing program failed for some reason.
c)It would have meant modifying the code of the above program to account for the difference in protocols between MAXC and Grapevine.

a) & b) are nice, but unnecessary. We need to know the new protocols so we can modify our software to fit in with Grapevine; it presently uses the MTP protocol.

2) Tape Reading.  I have used the MAXC programs TAPUT and EBCDIC to read VLSI projects submitted in tape form. MPC does write its own tapes, independent of MAXC, and I'm sure I could modify the program to read tapes. However if someone else has working programs that read tapes I would appreciate hearing about them.
	Cheers,
	Paul 

  

*start*
00619 00024 US 
Date: Tue, 6 Sep 83 19:44 PDT
From: Raim.pasa
Subject: Planning for the demise of Maxc
To: Taft.PA
cc: 1100Kernel^.PASA

Ed,

The 1100 Program at XSIS has been relying on MAXC for the following services:

	1)  Distributing Interlisp-D to the ARPA community

	2)  Exchanging software with ARPA

	3)  Distributing software in TOPS-20 Dumper format on mag tape

	4)  Importing software in TOPS-20 Dumper format 

	5)  Telnet access to the ARPA community

If these services are endangered, perhaps the 1100 Program can supply an expert to implement them before they vanish in '84.

--Marty Raim

	

*start*
01448 00024 US 
Date: Thu, 8 Sep 83 10:03 PDT
From: chiang.PA
Subject: The Demise of MAXC
To: Taft, RWeaver, IFSAdministrators^
cc: Berkovitz, Biegelsen, Dahlquist, DMoyer, Tuan, Zarzycki, Chiang
Reply-To: chiang.PA

I have received many responses echoing the concerns in the following message but no concrete suggestions. Since none of the users is a computer scientist, I am asking you to help us make the appropriate transition to a new file server or point us to someone who can do it.  	

Thank you in advance.

Anne
---------------------------

Date: Wed, 24 Aug 83 10:37 PDT
From: chiang.PA
Subject: The Demise of MAXC
To: Taft, RWeaver, IFSAdministrators^, Berkovitz, Biegelsen, Dahlquist, DMoyer, Tuan, Zarzycki
cc: Chiang
Reply-To: chiang.PA

For those of us still using ICARUS for circuit design (because of a lack of D machines and color monitors required by Chipmonk), there are some tape writing utility programs on MAXC which have to be maintained. These are PGT for generating IC masks on MANN 3000 machines, EBCDIC for making printed circuit board masks on the Gerber plotter, and the SAIL program needed for the execution of the two above.

I would like to know how we can transcribe and maintain these programs on another file server. Also, the people using Chipmonk must have a tape writing program of their own, what are they planning to do with it?

Anne

------------------------------------------------------------

*start*
01984 00024 US 
Date:  8 Sep 83 14:40 PDT
From: Masinter.pa
Subject: PARC-MAXC -> PARC-VAXC
To: Taft
cc: Masinter, Sheil, Winograd, BrianSmith

I believe that PARC and Xerox would be well-served by acquiring a VAX running Berkeley Unix. We could use it for a number of purposes:

a) ARPANET services
	TCP/IP implementations for VAX/UNIX are available and relatively
	complete and reliable. This would give us File transfer, Telnet access
	from DLS and a variety of other Arpanet services which would otherwise
	not be available without a great deal of software development. 

b) MAG-tape services
	A number of users at PARC and elsewhere occasionally need to interchange
	mag-tapes with other sites. A number of such utility programs are available
	for VAX/UNIX.

c) Ability to run at PARC software generated at other universities
	I believe that a majority of universities doing computer science research
	(and ARPA sites) are using VAX/UNIX for their software development.
	One of the original reasons for having Maxc was to be able to occasionally
	use such software at PARC. (For example, CLU runs on VAX/UNIX,
	as do a number of VLSI tools, etc.) 

Those are the benefits. The costs:

a) TCP/IP software exists already for VAX/UNIX, and is presumably low in cost.
   PUP and NS software for both 10 MB and 3MB Ethernet hardware.

b) I believe that a VAX 750 can be acquired for prices starting at $50K. A more serious configuration(e.g., a 780 with 600 MB disk, large memory, tape drives, ethernet) would probably run closer to $300K.

c) Hardware maintenance could be bought from DEC. DEC is beginning to supply UNIX as well, although getting from Berkeley would probably not be hard, given the ties with Berkeley.

d) There was some talk of the CLSI (?) acquiring a VAX at PARC. The source of funding, ownership, and timing may not fit well with the plans for replacing MAXC, however. If it did work out, it might be possible to share costs between the various users.

*start*
00854 00024 US 
Date:  9-Sep-83 14:12:51 PDT (Friday)
From: Malasky.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: Taft's message of Sun, 21 Aug 83 10:53 PDT
To: Taft, RWeaver
cc: Malasky

I'm not sure how interested you are in this, but one of the things we had to do for the Expert product was to add a way to write mag tapes.  Versatec's 791 (called Galaxy internally) is this product; it's been availabe for about a year now.

The Galaxy is simply an 8086 with a ethernet controller, magtape controller and plotter controller.  It speaks the same subset of the Filing Protocol that the MDE file tool uses.  In addition, we have written another tool (Tape Tool) which writes a few special format tapes (ANSI labeled among them).  We plan to make a variant of Brownie that will preserve directory structures on mag tapes.

	Bruce
*start*
01211 00024 US 
Date: 21 Sept. 1982 12:16 pm PDT (Tuesday)
From: RWeaver.PA
Subject: Synopsis ~ CSL External Services
To: Taylor
cc: RWeaver

Bob,

This is what I have so far.  I approached Ed Taft for more information and he is
going to talk to you to get a clearer idea of what you want.  I will continue to
gather information.  Ron...

Of the 774 directories on Maxc only 185 (less than 24%) are actual CSL
directories.  The remaining 76% are comprised of those at PARC but not
CSL (48%) and those external to PARC, which includes SDD, (28%).

Services provided by CSLs Maxc computer and the DLS to orgaizations
outside PARC include the following:

	1.  ARPANET access providing data links to other ARPA
	    hosts.

	2.  Mail facilities for remote or traveling users via the
	    DLS Telenet link.

	3.  Xerox family IFS Administrator access to PARC IFSs
	    via the DLS for file transfer to their local IFS.

	4.  

CSLs computer facilities provide services to such organizations in the
Xerox family as ADL, AMDS New York, ASM Rank-Xerox Sweden, ED Los
Angeles, EOS Pasadena, PD Los Angeles, PSD El Segundo, SDD Los Angeles,
Shugart, Versatec, Webster, XCS Los Angeles and Corporate Headquarters.
*start*
02082 00024 US 
Date: 21 Sep 83  7:48:36 PDT
From: RWeaver.pa
Subject: Re: Meeting to discuss Maxc decommissioning
In-reply-to: "Taft's message of Tue, 20 Sep 83 10:00 PDT"
To: Taft
Cc: RWeaver

Ed,


	Now it's my turn to say "sorry".  An urgent personal matter has developed
which will require that I leave work at 10:00 this morning.  I will not be able
to make the 11:30 meeting to discuss Maxc decommissioning.  I don't think my
absense will detract much since I would probably only listen and take notes.

	The main value of my presense would be to relay information regarding 
the VAX.  At the moment the situation can be described as rather bleak.  There
is a problem with the tape drive which causes the system to hang for varying
lengths of time ranging from several minutes to infinity (until a switch is turned
off on the tape controller or the system is rebooted).  DEC has been unable to
determine the cause of the problem, and is nearly ready to replace the entire
drive (according to the frustrated tech. rep.).  The drive also has developed a
run-away problem.  I have brought the problem of the Archive malfunction
to the attention of the GSL folks and the consulting expert but have yet to
receive a reply.  Most GSL VAX users that wish to archive their files also have
a Maxc account and use Maxc's Archive facility.

	I am attaching to a hard copy of this message and leaving it on your desk the
VAX Archive Procedures which was written by Jim Bratnober in February of 1980.
At that time it worked well with the then current version 2 of VMS.  As far as I
can tell the Archive and Retrieval system hasn't worked since verson 3 was
implemented.  I'm sure it can be made to work but I don't know of anyone in GSL
(except perhaps Jim Boyce) who can implement the changes.

	In view of the fact that I will not be able to attend the meeting, may I suggest
that Jim Boyce be invited to sit in my place?  I think he will have some 
constructive ideas to offer.  Again, my apologies for not being able to attend.
I'll be anxious to hear the outcome.

		Ron...

*start*
00730 00024 US 
Date: Fri, 23 Sep 83 18:15 EDT
From: Ziobro.Henr
Subject: Demise of MAXC
To: Taft.PA

Ed,
	 I run the Unix Vax in Henrietta.  It would be a shame to loose FTP access to arpanet.  Although we don't have a direct ARPA contract here I do depend on ARPA access to obtain programs from other hosts.  For example our VLSI software and Revision control software were obtained over the arpanet.  Anyone at a university who is giving something away free does not want to go through the hassle of distributing tapes.

	If you do shut down FTP service would it be possible to connect an IMP to our Vax here?  Since we will be running 4.2bsd Unix we will have a fully debugged TCP/IP implementation.

//Z\\
Jim Ziobro
*start*
00529 00024 US 
Date: Mon, 26 Sep 83 09:23 PDT
From: Buckley.pasa
Subject: Re: Planning for the demise of Maxc
In-reply-to: "Taft.PA's message of Sun, 21 Aug 83 10:53 PDT"
To: Taft.PA,
cc: Buckley

From your message, I take it that it will no longer be possible to access SRI or MIT via the Arpanet to bring files over, which is something I have occasionally had the need to do.  Is this one of the services that wil be going away when Macx is decommissioned?  Are there any plans to maintain this service?

Rob Buckley

*start*
00555 00024 US 
Date: Tue, 13 Sep 83 13:33 EDT
From: Lampson.PA
Subject: Re: Visit
In-reply-to: "Your message of Tue, 13 Sep 83 09:07 PDT"
To: Taft

OK, I've read it. Am I supposed to do anything? 

Wouldn't a user-FTP-only be quite a bit easier, and avoid all the security problems?

I think I agree with your conclusions. Getting a small VAX seems like a fine idea if some organization other than CSL will take responsibility for it. Otherwise it seems like a real sinkhole to keep it in sync with changing protocols internally and externally.

*start*
00736 00024 US 
Date: Tue, 13 Sep 83 10:57 PDT
From: Taft.PA
Subject: Replacing Maxc services
In-reply-to: "Your message of Tue, 13 Sep 83 13:33 EDT"
To: Lampson
cc: Taft

I don't think there is anything you are supposed to do besides express your opinions.  Taylor designated this list of people to consider the matter, and I expect he will want to call a meeting while you are here to make some decisions.

A user-FTP-only satisfies many but not all of the needs.  For example, Terry Winograd can't get files from PARC while he is at Stanford; XSIS 1100 software distribution becomes more cumbersome (it has to be pushed from this end rather than pulled by the customer); etc.  It's certainly better than no FTP at all.

	Ed

*start*
00470 00024 US 
Date: Tue, 13 Sep 83 15:25 EDT
From: Lampson.PA
Subject: Re: Replacing Maxc services
In-reply-to: "Your message of Tue, 13 Sep 83 10:57 PDT"
To: Taft

How about a machine with a Telnet server that can run the user FTP. Then  Terry or the XSIS customer can use Telnet to log onto this machine and do the transfers. I don't know whether the access control and other issues are easier for a Telnet server than an FTP server, but they probably are.

*start*
02030 00024 US 
Date: Mon, 3 Oct 83 14:52 PDT
From: Taft.PA
Subject: Maxc services
To: Birrell, MBrown, Lampson, Ornstein, Schroeder, RWeaver
cc: Taft

Two additional pieces of information to consider:

1. The Lisp group (which I assume means some combination of CIS and XSIS) is very interested in acquiring a VAX running Unix.  I have talked with Larry Masinter and Jon L. White about this, and also with a Unix wizard from Berkeley named Eric Cooper who works as a consultant (I don't know to which organization).  If this works out, it could solve our Arpanet FTP/Telnet access problem; and it would be vastly preferable to using GSL's VAX because CIS/XSIS have system software expertise whereas GSL does not.

(By the way, this VAX acquisition seems to be entirely separate from any machine acquisitions that might be made by the recently-established CSLI -- though there might be some potential for a cooperative effort.)

I suggest that now is perhaps a good time to do some negotiation at the next level up.

2. The archiving situation seems pretty hopeless.  The GSL VAX archive system is presently not working; their system support consultant is being terminated; they hope to hire someone full time but don't yet have any definite plans; and I suspect there would be serious operational problems such as VMS restrictions on file name length.

Surprising as it may seem, the situation with Unix is even worse.  According to Eric Cooper, there simply does not exist a Tenex-style archive system (selective archiving and retrieval with on-line directory).

So I think we are left with the need to roll our own archive system.  Butler's scheme seems like the least amount of work, though I would propose one addition: also keep some permanent log of archived files so that an on-line directory could be constructed at some future time (perhaps by someone interested in another Cedar data base application).

Unless there are objections, I will go ahead and advertise for a Cedar programmer to implement this.

	Ed

*start*
04450 00024 US 
Date: Saturday, 22 October 1983, 18:03-PDT
From: dekleer.PA
Subject: Planning for the demise of Maxc
To: Taft.PA, RWeaver.PA
Cc: Brown, dekleer

Your msg arrived while I was on vacation and the fact the MAXC would be
going away so flabergasted and depressed me (seriously) that I kept on
procrastinatng sending this msg. I had lunch with Fiala the other day
and that triggered me into sending this msg.  To put it briefly: I
REALLY REALLY wish MAXC could stay (in fact I refuse to believe it's
going away, I forsee wasting months of my effort making up for its
demise)).  Also getting rid of our PDP-10 puts that much distance
between us and the rest of the world.  Getting rid of MAXC will only
excacerbate the provincial attitude PARC has to the rest of the
computing science world.  Now all of our machines are of the home-grown
variety and we will only be able to run programs written here.  What
about things produced in the rest of the world?  How can we try out
someone's new mumblyfratz (e.g., a new PROLOG).  We won't be able to run
anyone else's software.  Other people can write interesting programs
too.  Admittedly, the PDP-10 is at the end of its days, but it still is
the most `universal' of machines.  There are piles of software existing
on PDP-10, most of which does not run on Xerox machines.  I'm going to
have a hard time enumerating them all--probably I will discover most of
them empirically after MAXC is gone.  If MAXC is unmaintainable why
don't we get a cheap FOONLY??  It's this sort of rationale that
contributed to MIT decided to buy their latest 10.  The absolutely least
thing we should do is prepare to rent time/space on someone else's
PDP-10.  I here rumours someone is thinking about getting a VAX to
replace MAXC, if you are thinking of doing that why not buy a FOONLY.

Here are some of my gripes (admittedly some are self-serving but it
illustrates the pain-in-the butt getting rid of MAXC is going to be for
me).

The only decent text preparation system available here is TEX.  All my
papers are written in TEX.  I hope a TEX server gets built.  Best
solution, have a server I can chat to run TEX and interact with it as on
TENEX.  E.g., \input phylum:<dekleer>core.tex.  If some solution to this
isn't found I am going to be fundamentally shafted.  

I use the archive system heavily.  If its going to be hard to retrieve
files from the archive tapes, I'm shafted.  I regulary copy files from
IFS's->MAXC for archive.  What should happen is an archive system for
IFS's in which previously archived TENEX files automatically appear.
Being paranoid I'm starting to go through my archive directory and
retrieving those files I can't afford to be without and copying them to
phylum.  (A further `waste' of my time and good space.)

How am going to run a MACLISP or INTERLISP-10 program?  I can't do it
without moving it to Lisp machines which often involves a lot more effort
than commonly advertised.

Editors.  Losing EMACS and its associated utilities is a disaster.  Its
by far the most powerful editor we have here, and we won't be able to
run it anymore.  Its the only editor that works over phone lines here.

I am used to editting papers at home.  I do this by dialing in and
running EMACS on MAXC.  What now?

I am used to reading mail at home with the identical system I use at
work.  Reading and answering mail at home will become impossible.  (That
dial in server on Ernestine is quite frankly a piece of junk compared to
BABYL).

TECO is the only editor that can hack truely huge files (i.e., 1000s of
pages).  

Sure there is a mag tape server, but what about all the related
software?  Reading and playing with tapes is going to be much harder.  I
used to be able to run TAPUT/DUMPER on MAXC to put the stuff in TENEX
files and then copy these files to phylum.

All good PROLOGs run on the 10.  How can we play around with PROLOG?

If I read your msg right, there is going to be no plans to implement
ARPANET ftp and telnet.  What!?  Suppose I want to run some program at
MIT, or transfer files.  FTP can be partially accomplished by sending
humongous msgs (but msgs bigger than 10K chars get squashed).  How can I
copy binary files.  I'll have to go back to shipping tapes back and
forth --- and there is doubt that is even going to work if all there
is going to be is a tape server protocol.

So, you see I wish that MAXC's demise be delayed as much as possible.

-------
*start*
01179 00024 US 
Date: Mon, 24 Oct 83 10:23 PDT
From: Taft.PA
Subject: Re: Planning for the demise of Maxc
In-reply-to: "dekleer's message of Saturday, 22 October 1983, 18:03-PDT"
To: dekleer
cc: Taft, RWeaver, Brown

Thanks for your message.  As you might expect, I've gotten quite a lot of feedback already on my message about Maxc; that was my intention in wording it the way I did.

There have already been some substantial changes in plans.  Briefly:

  1) We are building a new archive system that is independent of Maxc.  It will be able to archive files from IFS and other servers that support FTP.
  2) Maxc will not be shut down until some alternative arrangement has been made for Arpanet FTP and Telnet access.  There are several possibilities now under investigation (e.g., item 3).
  3) There are efforts afoot in CIS and XSIS to acquire a VAX.  If this happens, many of the popular time-sharing services (e.g., Emacs, TEX) will be available.

It's to be expected that decommissioning Maxc will entail some inconvenience.  But we must weigh this against the costs of continuing to operate a system that uses obsolete hardware and unsupported software.

	Ed

*start*
01678 00024 US 
Date: Mon, 24 Oct 83 12:13 PDT
From: Taft.PA
Subject: Maxc decommissioning and CIS/XSIS VAX
To: Schroeder
cc: Taft

Mike,

Among the major services now provided by Maxc, the only one that we (CSL) have not made plans to replace is FTP/Telnet access to the Arpanet.  This service is sufficiently important to many users that I consider its replacement to be a prerequisite to decommissioning Maxc.

I've had discussions with several people in CIS and XSIS about this, primarily with Larry Masinter and Jon L. White.  They have told me that both organizations have considerable interest in acquiring a VAX.  I understand that this machine would be used by CIS to run software they would like to import, and by XSIS to enable better support to many of their customers who have VAXes.

If these plans work out within the correct time frame (say, by the end of the first quarter of 1984), the VAX could be used to provide the Maxc replacement service for Arpanet FTP/Telnet access.  I've also talked with Eric Cooper, a Berkeley Unix wizard who consults for XSIS; he assures me that there would be no technical problems with this approach.

Providing this service on a VAX operated by CIS and XSIS would be vastly preferable to using the GSL VAX for this purpose, in my estimation.  There are several reasons for this, chief among which is the fact that CIS and XSIS have considerable systems programming expertise whereas GSL has none at all.

At this time, I am requesting you to take up this topic at the appropriate levels of management, particularly to find out how real these VAX plans are and when they are likely to be put into effect.  Thanks.

	Ed

*start*
00433 00024 US 
Date: Fri, 30 Dec 83 14:40 PST
From: Taft.PA
Subject: Re: Maxc Sort program
In-reply-to: "RWeaver's message of 28 Dec 83 09:22:29 PST"
To: RWeaver
cc: Taft, Mannes

There are no plans to implement a replacement for the Maxc Sort program. I do not know exactly what it does; but I suggest that the Laurel LineSort program and the sorting operations of the Cedar EditTool might be acceptable substitutes.

	Ed

*start*
04557 00024 US 
Date: Thu, 19 Jan 84 17:08 PST
From: Taft.PA
Subject: BSYS archive tape format
To: Diebert
cc: Taft

Each record on the tape consists of some integral number of Maxc words encoded as 6 bytes each. The first 4 bytes contain the leftmost 32 bits of a Maxc word; then there is a byte of garbage; and finally there is a byte containing the rightmost 4 bits of the Maxc word followed by the 4 "tag" bits, which you should ignore.

Hereafter, whenever I say "word" I mean 36-bit PDP-10 word as interpreted above. The notation a,,b means a in the left 18 bits and b in the right.

The remaining information is gleaned by reading the BSYS listings. I do not certify it as being 100% accurate, but it should be close enough to permit figuring out the truth after examining an existing archive tape or two.

A file on the tape (including the directory file at the beginning) consists of a header block followed by some number of data blocks. Each block (both header and data, but not including the directory's header block) has the following structure:

  Block number (1 word). All the blocks on the tape are sequence numbered starting at zero. File marks don't count as blocks in this numbering.

  file,,page number (1 word). All the files on the tape are sequence numbered starting at zero, and each block of a file has the same file number. The page number is the logical location of the page within the file, starting at zero. Page numbers are in ascending order, but they are not necessarily sequential since Tenex files can have "holes" (missing pages) in them. Such files are relatively rare, but there is one case you will not be able to avoid: the directory file is full of holes. The header block at the beginning of a file has a page number of 777775B.

  data (512 words)

  page protection (1 word). I suggest you ignore this information!

515 words total.

A file's header block has the following information in its data field:

  FDB (File Descriptor Block, 21 words). This is given below.

  Name string block (variable). String block format is given below.

  Extension string block (variable)

  Account string block if any (variable). I doubt you will care about "accounts" in the Tenex sense.

  Padding (variable, to fill out 64 words)

  Directory number (1 word, located at word 64 of the data field). I don't believe directory numbers are of any interest to you.

  Directory name string block (variable).

The following stuff in the FDB may be of interest. I'm omitting information that I don't think is useful; the complete truth may be found on page 7 of the BSYSDF listing, or page 2-63 of the Tenex JSYS manual.

  Word 1: garbage ,, pointer to name string. A "pointer" here is an offset relative to the start of the data field.

  Word 2: pointer to extension string ,, garbage

  Word 4: file protection

  Word 7: version number ,, garbage

  Word 9: bits 6-11: byte size
            right half (bits 18-35): number of pages in file. This can differ from the page number of the last page plus one if the file has holes.

  Word 10: Length of file in bytes (of the byte size given in word 9). Tenex files of any byte size have bytes packed left-to-right in each word, with any leftover bits at the right thrown away. That is, a 7-bit file (which is standard for ASCII text) packs 5 bytes per word with one bit wasted.

  Word 11: File creation time. Time in Tenex is measured from midnight, November 18, 1858, GMT. The number of days is in the left 18 bits and the number of additional seconds is in the right 18 bits. To translate this to a "Pup time", take the left half, subtract 15385, multiply by 86400, and add the right half. Then, to turn this into a BasicTime.GMT, call BasicTime.FromPupTime.

String block format:

  Word 0: garbage ,, size of block in words (including this word)

  Words 1 through n-1: 7-bit ASCII text string, padded with at least one zero byte at the end.

A file name is broken into four pieces: directory, name, extension, and version. The directory, name, and extension are stored as separate strings, and the version is stored as an integer. The punctuating characters "< > . ;" are not included in any of the strings, but must be supplied by the software that reconstructs the file name from the separate components.

I believe this is everything you need to know about all files on the tape except the directory. I'll go into directory format in a separate message. I suggest you preserve this information as comments somewhere in the source files for your software.

	Ed

*start*
03928 00024 US 
Date: Fri, 20 Jan 84 10:48 PST
From: Taft.PA
Subject: BSYS tape directory format
To: Diebert
cc: Taft

The tape directory consists of a header, which is NOT in the standard header format, followed by exactly 200 data pages containing the directory, followed by a file mark, followed by 18 inches of blank tape. When the directory is rewritten, it is followed by only 9 inches of blank tape. This is to assure that when it stops writing there is blank tape underneath, so there are no glitches.

The header block is 64 words long. I think the only interesting piece of information is the tape number, which is in word 1. (The complete definition of a tape header is on page 10 of BSYSDF.)

The directory is an ordinary file, as described in my previous message. But there are two unusual things about it: (1) it has lots of "holes", and (2) there are some number of unused pages at the end (to fill up the 200 pages), marked with a file,,page number word of all ones.

The directory file is organized as some number of "user directories", each of which is up to 16 pages long and starts at a 16-page boundary. Each directory has a "directory number" in [0..1023]; directory number n starts at page 16*n in the file. Most directories use fewer than 16 pages. The directory file contains only those pages that are actually used, which is why it has lots of holes.

Each "user directory" is considered as an independent data structure; that is, you have to look at all 16 (or fewer) pages at once. It's full of pointers, which are all relative to word zero of page zero of that user directory. Directory number zero is special and will be described later.

A user directory consists of three regions, in this order: a fixed region, a variable region, and a symbol table. The fixed region starts at word 0 of the directory. The only things in it that I think you will find useful are:

  Word 3: pointer to first word of symbol table
  Word 4: pointer to first word beyond end of symbol table

The symbol table is shoved up against the end of the last page actually used in the user directory. The variable region is where all the name strings, FDBs (file descriptor blocks), and other stuff are located.

The symbol table is an array of one-word entries, each of which contains a pointer to a name string in the left half and a pointer to an FDB in the right half. This table is sorted by name. I should mention at this point that all name strings in Tenex are stored literally and that all characters except null are legal; upper and lower case are NOT equivalent. Lower case letters are usually converted to upper case as they are typed in, so you will find that nearly all stored file names are entirely upper case.

The string block format and FDB format were given in my previous message. The FDB pointer gets you to an FDB for SOME file with that name; you find the actual extension and version by looking at the left half of word 2 and the left half of word 7 respectively. Starting at this FDB, there are chains of other FDBs for files with the same name but different extension or version or both. Specifically, the right half of word 2, if nonzero, points to another FDB with the same name but different extension. The right half of word 7, if nonzero, points to another FDB with the same name and extension but a different version. The FDBs along a version chain are in descending order of version number.

That is everything you need to know about ordinary user directories. Directory number zero is special: it contains a symbol table that maps directory names to directory numbers. Words 3 and 4 describe the symbol table as described above. Each symbol table entry has a pointer to a directory name string in the left half and a directory number in the right half. Once you have the directory number, you multiply it by 16 to get the page number of the first page of the user directory.

	Ed

*start*
01091 00024 US 
Date: Sun, 22 Jan 84 11:19 PST
From: Taft.PA
Subject: Addendum to BSYS tape directory format
To: Diebert
cc: Taft

Normally, when an error is detected during writing, the conventional error retry mechanism is invoked: erase the block and write a new one further along the tape, leaving a larger-than-usual gap.

However, if an error is detected while writing the directory, doing that is not acceptable, since BSYS would no longer have good control over the exact amount of tape consumed. Instead, BSYS leaves the bad block as it stands and simply writes another copy in the next block. Of course, it later compensates for this by writing one fewer dummy blocks at the end to fill out the standard 200-page file.

This means that when reading the directory, you may find more than one copy of a page in consecutive blocks, and the first page may or may not be readable. When you detect a read error while reading a directory page, try reading the next one. If it has the correct block number then it is a copy of the unreadable page, which you can then ignore.

	Ed