perm filename FTP.MSG[1,LES]2 blob
sn#337880 filedate 1978-02-28 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00022 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00004 00002 ∂07-APR-76 1115 BH via MITT MISCELLANY
C00005 00003 ∂05-OCT-76 0057 MRC via RTGT DFTP PROGRESS REPORT
C00007 00004 ∂14-OCT-76 1105 FTP:JF at CCA Re: File System Access
C00010 00005 ∂14-OCT-76 1526 FTP:MRC at MIT-AI (Mark Crispin ) DFTP version 2
C00014 00006 ∂26-OCT-76 2214 FTP:MRC at MIT-AI (Mark Crispin ) Datacomputer
C00020 00007 ∂01-Nov-76 2048 FTP:MRC at MIT-AI (Mark Crispin ) GOOD NEWS ABOUT DATACOMPUTER
C00021 00008 ∂10-Nov-76 2129 MRC via RTGT NEW DFTP TO NEW DATACOMPUTER
C00024 00009 ∂11-Nov-76 1640 FTP:MRC at MIT-AI (Mark Crispin ) DFTP
C00028 00010 ∂11-Nov-76 1408 LES DFTP
C00029 00011 ∂19-Nov-76 1843 FTP:MRC at MIT-AI (Mark Crispin ) ITS NDFTP, documentation...
C00031 00012 ∂25-Nov-76 2244 FTP:MRC at MIT-AI (Mark Crispin ) ITS DFTP
C00043 00013 ∂03-Dec-76 2332 FTP:MRC at MIT-AI (Mark Crispin ) For your information
C00050 00014 ∂06-Dec-76 1358 FTP:DEE at CCA APOLOGIES FOR 203 DATACOMPUTER AVAILABILITY
C00052 00015 ∂16-Dec-76 1340 FTP:REM at MIT-MC (Robert Elton Maas ) CCA Datacomputer TBM, DFTP
C00055 00016 ∂05-Feb-77 1519 REM DFTP and FTP
C00059 00017 ∂05-Feb-77 1918 REM DFTP primer
C00060 00018 ∂10-Feb-77 0657 FTP:JF at CCA User Support Contacts at the Datacomputer
C00062 00019 ∂10-Feb-77 2315 REM via AMET DFTP speed
C00063 00020 ∂07-Jun-77 0046 REM via AMET ∂07-Jun-77 0037 REM via AMET Bug still happening, my first try since giving up yesterday gave this:
C00065 00021 ∂01-Dec-77 1814 BH via AMET proposed incompatible change to FTP
C00066 00022 ∂28-Feb-78 0116 RAK Cutesies from MRC
C00068 ENDMK
C⊗;
∂07-APR-76 1115 BH via MITT MISCELLANY
I HAVE PASSED THE THING ABOUT THE FTP SERVER LOSING TO MARTY.
WE SHOULDN'T BE LOSING DATA; IT IS TRUE THAT WE DON'T SUPPORT
RETRANSMIT. I DIDN'T THINK ANYONE DID. I'LL MAIL YOU SOME
RESTAURANTS FROM PARIS WHEN I GET BACK. I AM ALSO GOING TO
ATTEMPT TO HACK TYMNET INTO SUMEX UNOFFICIAL;LY. I AM BENDING
EVERYONE'S EAR AT DECUS ABOUT SOFTWARE SUPPORT FOR DISPLAYS.
∂05-OCT-76 0057 MRC via RTGT DFTP PROGRESS REPORT
To: REM, LES
WELL, IT NOW WILL WORK TO CONNECT TO THE DATACOMPUTER, GET OUT THE
RIGHT DATALANGUAGE, AND YOU CAN DO THINGS THAT DON'T REQUIRE
THE AUXILLARY NETWORK CHANNELS SUCH AS DO DIRECTORIES, ETC.
COPYING FILES IN ANY WAY WON'T WIN, THOUGH, BECAUSE THAT CODE ISN'T
WRITTEN YET, BUT THERE IS ENOUGH WORKING JUST TO EXPERIMENT WITH AND
SEE THAT I AM GETTING ALONG(WITH SOME ASSISTANCE FROM ME...).
∂05-OCT-76 0105 MRC via RTGT
I LOOKED AND THERE IS NO SAIL OR SU-AI NODE IN THE DATACOMPUTER YET,
BUT THERE IS A SUMEX NODE.. WELL, FOR THE TIME BEING, I'VE SET IT
TO USE THE ITS NODE.
∂08-OCT-76 1801 MRC via RTGT DFTP NODES
To: LES, REG
I CREATED NODES ON THE DATACOMPUTER UNDER THE ITS NODE FOR BOTH
OF YOU, ASSUMING YOU WOULD WANT TO EXPERIMENT. I DIDN'T PUT A
PASSWORD ON THEM. WHEN YOU RUN DFTP, IT WILL AUTOMATICALLY
LOG YOU INTO YOUR NODE ON THE DATACOMPUTER(IT DOES
A GETPPN AND LOGS IN AS DFTP.ITS.<PROG #> IF IT CAN'T DO
THAT BECAUSE IT DOESN'T EXIST, THEN IT LOGS YOU IN AS DFTP.GUEST).
MARK
∂14-OCT-76 1105 FTP:JF at CCA Re: File System Access
Date: 14 OCT 1976 1201-EDT
From: JF at CCA
Subject: Re: File System Access
To: LES at SU-AI
cc: WRB, GEOFF at SRI, MRC at AI
In response to your message sent 27 SEP 1976 1333-PDT
First, my apologies for delaying so long in answering. We have a
program, called DFTP, which is built to transfer files to/from the
Datacomputer. It was developed here, and has been used from
several sites on the network, including SRI, for several years;
Geoff Goodfellow has been our liaison there and can tell you
something about it. One recent feature which he may not have been
exposed to yet is the capacity to store or retrieve classes of
files at a time (like TENEX' "*" feature). I think this should make
it especially appropriate for your backup application, or as a
solid base for a demon you might wish to write yourselves.
The reason I delayed responding is that we are in the midst of
converting DFTP's internal storage format to one that will use
the TBM and the Datacomputer directory much more efficiently.
I have been expecting to release it momentarily for several weeks
now, and was waiting for that event. We have been hampered by
the necessity of transferring existing data to the new format.
However, since SU-AI doesn't have any existing data, it
might be reasonable to start you fresh with the new format more or
less immediately. The copy we have of the new DFTP runs under
TENEX and TOPS-10; Marc Crispin (MRC@MIT-AI) has generated ITS
and SAIL versions of the old program, and I believe is about
to work the same transformation on the new one. Would
you like to start with our TOPS-10 edition, or do you want to wait
for him?
Jerry Farrell
-------
∂14-OCT-76 1526 FTP:MRC at MIT-AI (Mark Crispin ) DFTP version 2
Date: 14 OCT 1976 1824-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: DFTP version 2
To: REM at MIT-AI, MSC at MIT-AI, AHR at MIT-AI, MACRAK at MIT-AI
To: MAC at MIT-AI, RG at MIT-AI, MRC at MIT-AI, BRONS at MIT-AI
To: DFTP-USERS at MIT-AI, LIS at SU-AI, TVR at SU-AI, JMC at SU-AI
To: LES at SU-AI, REG at SU-AI, JP at SU-AI, JLK at MIT-MC
Message-ID: <[MIT-AI].12426>
CCA has annnounced DFTP version 2, which, unfortunately, does
not have my edits for the SAIL and ITS versions.
This new DFTP will use the terabit memory and has nice hacks
such as wildcarding, etc., and also will soon replace DFTP
version 1. Hopefully, the service will be much better and a
general improvement, but in the next few months expect some minor
hassles.
I created this mailing list to keep you all informed about developments
as they happen; hopefully the only changes you will see are changes
for the better.
I hope to have the ITS and SAIL new DFTP up in a couple
of weeks; it depends on what happens with my time, since I am still
(theoretically) a full-time student...
Mark
∂18-OCT-76 2334 FTP:MRC at MIT-AI (Mark Crispin ) DFTP
Date: 19 OCT 1976 0113-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: DFTP
To: REM at MIT-AI, MSC at MIT-AI, AHR at MIT-AI, MACRAK at MIT-AI
To: MAC at MIT-AI, RG at MIT-AI, MRC at MIT-AI, BRONS at MIT-AI
To: DFTP-USERS at MIT-AI, LIS at SU-AI, TVR at SU-AI, JMC at SU-AI
To: LES at SU-AI, REG at SU-AI, JP at SU-AI, JLK at MIT-MC
Message-ID: <[MIT-AI].14043>
CCA has informed me that the changeover from the version 1 to
version 2 Datacomputer will be gradual, so there is no need to
worry about hassles yet. It looks like I will have the new DFTP
at least in an experimental version this weekend if I can get up
to AI and do heavy editing then(barring foul weather and evil
fortune...).
If you're interested in some nifty info on what to expect in the
new DFTP, read the file:
on MIT-AI: MRC;NDFTP CRUFT
on SAIL: NDFTP.CFT[NET,MRC]
∂26-OCT-76 2214 FTP:MRC at MIT-AI (Mark Crispin ) Datacomputer
Date: 27 OCT 1976 0114-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: Datacomputer
To: LES at SU-AI
Message-ID: <[MIT-AI].18270>
I see that Jerry Farrel (JF@CCA) has created a SUAI
node on the Datacomputer. It would help me in debugging the SAIL
DFTP if i could hack it, but I do not know the password for that
node(presumably JF doesn't want to tell me without your okay, although
I do have the ITS node password)...Has he given it to you?
If you do tell me, and don't want it to go out, it's safest not to
use mail since there are people who read my mail on AI and my
Stanford mail gets sent over. Probably the best thing is just to
write a file on my Stanford directory with it in there.
I'm halfway done on gettting the Stanford DFTP for the new
Datacomputer running, and maybe will have it ready by the end of the
week...
Mark
∂29-Oct-76 0325 FTP:MRC at MIT-AI (Mark Crispin ) SAIL DFTP
Date: 29 OCT 1976 0618-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: SAIL DFTP
To: DFTP-USERS at MIT-AI
CC: DFTP-HACKERS at MIT-AI
Message-ID: <[MIT-AI].19323>
Good news! SAIL DFTP is now up and ready to go. The
file dftp.mrc[up,doc] (or, on ITS: .info.;dftp order) contains the
old manual with an introductory buzzwah handwave statement from
on high(ie, CCA) about the new DFTP.
Also, SAIL has its own node on the Datacomputer now, the SU-AI
node.
I shall contact CCA and arrange for SAIL users to be transfered
over to the new terabit memory Datacomputer as soon as practical.
For those who would like to try the new DFTP, run DFTP from
[net,mrc](the one on SYS: is the same old one)...but none of your
directories are there yet, and I can't create any directories on
the new Datacomputer for SAIL, because (as yet?) I do not
know the node's password.
For iTS users; I am going to start work on the ITS DFTP
now and maybe will have it ready in another week, and I DO have
the psw for that node, so once ready, I'll start creating dirs for
everybody here.
Mark
∂29-Oct-76 2140 FTP:MRC at MIT-AI (Mark Crispin ) Good news and bad
Date: 30 OCT 1976 0039-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: Good news and bad
To: DFTP-HACKERS at MIT-AI, DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].19656>
First the good news,...
Barring flaky network andOr systems, or something happening here,
the ITS version to hack the new DC will be ready this weekend,
and we can start moving stuff over.
The ITS and SAIL users will be separated at this point, since
SAIL now has its own node(the SUAI node). It appears that
there will be too many hassles to leave things the way they are...
As for the bad news:
"Our (MIT-AI's) position is that it is presently not willing
to pay anything[for DC usage]. There is no way that any real money
can be committed without much prior approval by PHW, etc."
What this means is that if CCA does start charging for using the
DC, this service may vanish without notice for ITS people.
What SAIL and individual groups in the ITS community do, of
course, isn't dependent upon AI's actions, but some hassles can
result.
Hopefully CCA will relent on charging since it is a useful
resource on the network, and one that should be continued. Also,
I have enjoyed hacking DFTP quit a bit, and was hoping to
eventually have ITS and SAIL versions of DCSUBR so other programs
to hack the DC would be possible...
Well, what will happen will happen, and we can just cross fingers and
hope for the best!
Mark
∂01-Nov-76 2048 FTP:MRC at MIT-AI (Mark Crispin ) GOOD NEWS ABOUT DATACOMPUTER
Date: 1 NOV 1976 2316-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: GOOD NEWS ABOUT DATACOMPUTER
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].21052>
WORD FROM CCA:
" DON'T WORRY ABOUT BEING CHARGED. HARVARD FEELS THE SAME
WAY. THERE ARE NO PLANS TO CHARGE FOR AT LEAST TWO YEARS.
ACCOUNTING ROUTINES ARE CURRENTLY BEING PUT INTO THE DATACOMPUTER,
BUT REAL BILLING WILL NOT HAPPEN IN THE FORESEEABLE FUTURE."
CELEBRATE, PARTY, ETC...
∂10-Nov-76 2129 MRC via RTGT NEW DFTP TO NEW DATACOMPUTER
To: REM, JP, REG, LES, JMC, TVR, LIS
I'VE CREATED NODES FOR ALL OF YOU ON THE NEW DATACOMPUTER, INCLUDING
THE HOST/PASSWORD RESTRICTIONS THAT I REMEMBERED(IE, FOR JP AND LIS).
THE OTHER HAVE NO RESTRICTIONS AT ALL SET ... IF YOU WANT THEM,
DO:
.R NDFTP
[ATTACHING]
*ENABLE
!CHANGE <
[OK]
ADD A NEW PRIVILEGE? Y (JUST TYPE THE "Y", IT WILL TYPE "ES")
AND THEN ANSWER THE OTHER QUESTIONS IT ASKS. IT WILL MORE OR LESS
LEAD YOU BY THE HAND.
TWO THINGS TO NOTE: [1] CHANGING THE PROTECTION STATUS OF YOUR NODE WILL
DELETE THE PREVIOUS STATUS. IF YOU WANT TO HAVE DIFFERENT STATUS
FOR DIFFERENT HOSTS, IT MUST BE DONE WITH THE SAME CHANGE COMMAND.
[2] I STRONGLY ADVISE AGAINST USING ANY USER OR SOCKET RESTRICTIONS
AS SAIL AND ITS PICK RANDOM SOCKETS FOR A USER TO USE, UNLIKE TENEX
OR ITS.
IF YOU HAVE A PASSWORD PROTECTED NODE WITH CONTROL(IE, WRITE AND MODIFY
) PRIVILEGES AND A NON-PROTECTED NODE WITH READ PRIVILEGES, DFTP WILL
AUTOMATICALLY TAKE YOU TO THE READ-ONLY PRIVILEGE LEVEL. YOU MUST
DO: ATTACH <<<SUAI>YOUR-PROGRAMMER-NAME:YOUR-PASSWORD TO GAIN ACCESS
TO THE CONTROL LEVEL. I EXPLAINED IT FULLY TO REM, AND SINCE HE IS
3,000 MILES CLOSER THAN I AM TO YOU, HE COULD DO A BETTER JOB THAN I CAN
IN EXPLAINING ALL THE TRICKS(IT TOOK ME SEVERAL HOURS).
THE NEW DFTP IS A LOT SLOWER, BUT HAS MUCH MORE STORAGE AND SHOULD BE
EASIER TO USE. YOUR FILES ON THE OLD DATACOMPUTER HAVE NOT BEEN COPIED
OVER YET, HOPEFULLY CCA WILL DO SO THIS WEEKEND.
IF YOU HAVE ANY QUESTIONS, SEND THEM TO ME HERE OR IF YOU'RE WORRIED
ABOUT KEEPING A PASSWORD SECRET(SINCE NEITHER MY MAILBOX AT SAIL OR
MIT-AI IS SECURE AND SEVERAL PEOPLE READ MY MIT-AI MAILBOX), SEND
ANY REQUESTS TO MARK%SRI-AI.
ENJOY!
MARK
∂11-Nov-76 1640 FTP:MRC at MIT-AI (Mark Crispin ) DFTP
Date: 11 NOV 1976 1938-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: DFTP
To: les at SU-AI
Message-ID: <[MIT-AI].25542>
Got your message. I've started creating your nodes, as you've
noticed in your other mail. I don't know when CCA will slosh
over existing files on version 1 DC...but then again, I don't
think too many people used version 1 because it was temporary.
Oh, in case you're wondering, I can send upper+lower case mail
from MIT-AI but not from SAIL because ITS' mailer has
a "/" option where the default insertion case is lower case, and to
enter upper case characters, you preceed it with a "/". Of course,
using this mode can cause problems; I think you got a message that
had "i/o" as "iO" or something...I figure people appreciate getting
more readable mail, so I do it. I guess hardly anybody at SAIL
uses 10cps uppercase only terminals any more.
I noticed the SAIL system message about a forthcoming disk
purge; so I cut my directory to 40 blocks since I believe I
was slightly above allocation(like 70 or so)...and if this new
DFTP works as I believe it does(my testing has uncovered no
problems that can't be blamed on network problems or CCA being
down or SAIL or CCA being heavily loaded) then maybe it
might be a good idea to advertise it as a good place to put largish
or not often used files and encourage people to use it for such.
I was surprised to discover than SAIL had online the complete
text of "Wuthering Heights" and "Grimm's Fairy Tales"... But
I'd want to wait and see maybe having parallel copies or something
until it seems like a winner to the users. I find it hard to
understand why any system ever has disk crisises; although I'm one
of these people who can't go to sleep at night knowing that I left
a backup version of a file or a REL file or something on line(even
when the system crashed and it wasn't my fault) so I guess I
wouldn't be able to understand how the less-hackish want to keep
their directories.
Happy hacking and all that.
Mark
∂11-Nov-76 1408 LES DFTP
To: mrc at MIT-AI
I finally got around to talking with Jerry Farrell @ CCA. The password
for the SUAI node is HALYARD.
∂19-Nov-76 1843 FTP:MRC at MIT-AI (Mark Crispin ) ITS NDFTP, documentation...
Date: 19 NOV 1976 2142-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: ITS NDFTP, documentation...
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].29650>
ITS NDFTP now works well enough to perform all functions
except for PUT, but wildcards on GET, etc... all work as do
creation dates. This ndftp only exists on AI. Please hold bug
reports until it is completely finished...
WRB@CCA is promising new Datacomputer documentation any
minute now, maybe I'll have it up on SAIL and ITS tommorrow.
Tenative date for full slosh from v.1 datacomputer to v.2
is next weekend....
Hope this info is useful...
Mark
∂25-Nov-76 2244 FTP:MRC at MIT-AI (Mark Crispin ) ITS DFTP
Date: 26 NOV 1976 0143-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: ITS DFTP
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31319>
ITS DFTP has been (finally) finished. The old one is called
ODFTP, but it will go away imminently, as soon as CCA gets
the files there copied over to the new datacomputer.
Differences: [1] files are entered in Tenex format, ie fn1.fn2, [2]
it is now not possible to enter either Sname or device name,
[3] entire structure has undergone major modifications.
.info.;dftp order has as best documentation as is available; mostly
the old doc file with a very brief update page on top. I have
been promised documentation "any day" now for 4 weeks... anyway,
I'll announce ITS DFTP to the ITS world when I get the
documentation stashed away on .info.;...
Enjoy!
Mark
∂26-Nov-76 1201 FTP:JF at CCA RELEASE OF NEW DFTP
Date: 26 NOV 1976 1439-EST
From: JF at CCA
Subject: RELEASE OF NEW DFTP
To: DFTP LIAISONS:
cc: ROTHNIE
A new version of DFTP is being installed at all sites. This
version is compatible at the command level for most users.
However, there are a number of extensions and changes in
relatively infrequently used parts of the system; people who
make extensive use of subdirectories (using the CONNECT command)
may find themselves particularly affected.
Documentation for the new version exists in both the old and
new versions of DFTP. In the old, it can be retrieved by the
following sequence:
@(O)DFTP
[ATTACHING]
*GET <<<COMMON>DFTP.NEW-MEMO
[OK]
*QUIT
In the new version:
@(N)DFTP
[ATTACHING]
*GET <<<COMMON>DFTP>NEW.DOC
(SXCFS: STAGING DATA FOR FILE = DFTP.COMMON.DFTP."<FILES">)
(SXCFS: STAGING DATA FOR FILE = DFTP.COMMON.DFTP."<FILES">)
{OK}
*QUIT
The new version of DFTP is distinguished by several
features:
1. Availability. New DFTP runs on ITS, SAIL, TENEX,
TOPS-10, and TOPS-20 systems; it is also being
implemented on MULTICS.
2. Capacity. New DFTP uses a mass store, an Ampex Terabit
Memory System (TBM). This device currently provides an
on-line capability of about 200 billion bits, expandable
up to 3.2 trillion (10**12) in the full configuration.
As a consequence, most users have had their allocations
increased. As another consequence, users may expect
noticeable delays when they first access data, as it is
moved from tertiary to secondary storage. These delays
may range from a few seconds to several minutes; they
will be signalled by a message like the one appearing in
the example above.
3. New storage structure. The new DFTP collects files for
a user into one or more large Datacomputer files. This
new organization is much more space-efficient than the
old; it should also serve to minimize delays for staging
from tertiary storage.
!
4. Extended functions. Several new features follow from
DFTP's new file organization:
a. File Sets. Commands which refer to files may now
specify a set of files in place of a single file,
by use of an asterisk in a file name field. This
operates like a "wild card", matching any value
in that field. For example,
*PUT FOO.*
(FOO.DOC)
(FOO.MAC)
(FOO.REL)
(FOO.SAV)
stores all four files in the user's directory
which have a first name of "FOO", with a single
command.
b. File version numbers. DFTP now maintains an
internal version number, so that several
different version of the same file may be kept
and retrieved individually.
c. DELETE, UNDELETE, and EXPUNGE. The effect of
DELETE is now revocable; until an EXPUNGE
command is executed, deleted files may be rescued
and returned to normal status. EXPUNGE should be
a fairly infrequent operation, used to reclaim
space when an allocation is filled with unwanted
files.
d. Increased directory information. The amount of
information kept with a file has been increased
significantly. DFTP now keeps a local write
date, a DFTP store date, file bytsize, length in
bytes, full-length file names, and a checksum.
This information contributes added convenience to
users. It also provides full-circle integrity
checking, with the same checksum computed and
checked throughout the file's handling by DFTP.
Full decscriptions of these and other aspects of the new DFTP
are contained in the document mentioned above.
!
Details of Conversion
The new version of DFTP has existed for several weeks, undergoing
testing at CCA, HARVARD, MIT-AI, and SUAI. It is now being
installed at all DFTP sites throughout the network. Users' data
is being transferred to the new format on the TBM by CCA. The
old data, accessible by the old version of DFTP, will be kept
available for at least a week; but allocations will be set to
prevent any further data from being stored in the old system,
once a site's data has been transferred to the new version. CCA
will attempt to arrange with site liaisons so that both versions
will be available to users, with the new version called NDFTP
until the site's data has been transferred, and renamed to DFTP
at that point. Similarly, the old version will be called DFTP
before, and ODFTP after the transfer at each site.
Questions, complaints, and suggestions should be sent to
FARRELL @ CCA
-------
∂26-Nov-76 2120 FTP:MRC at MIT-AI (Mark Crispin ) New DFTP from CCA
Date: 27 NOV 1976 0018-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: New DFTP from CCA
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31608>
CCA distributed a new DFTP which I just installed on ITS
and SAIL. There are some bug fixes to what users have
complained about recently, and two minor external changes:
[1] QUIT requires confirmation.
[2] No password query on original attach; if you have a
psw protected node, you will be logged in as DFTP.GUEST.
This is because version 3 Datacomputer(they're already
talking about v.3...) will not allow LIST without LOGIN
and so no way to determine if login failure due to bad node or
bad password. To get to your node if you are attached as
DFTP.GUEST, do:
*attach <<<suai>foo>:mumble
if your user name is foo and psw mumble. [Of course, that is
for a Stanford person, but I don't know of any ITS users
with passwords.]
People without passwords will not be affected by this; they
will continue to have autologin as always.
∂26-Nov-76 2129 FTP:MRC at MIT-AI (Mark Crispin ) correction
Date: 27 NOV 1976 0027-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: correction
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31611>
The incantation is:
*ATTACH <<<SUAI>FOO:MUMBLE
not
*ATTACH <<<SUAI>FOO>:MUMBLE
(the psw will not be echoed).
Sorry.
∂03-Dec-76 2332 FTP:MRC at MIT-AI (Mark Crispin ) For your information
Date: 4 DEC 1976 0226-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: For your information
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].34620>
The following is a blurb from CCA about the new DFTP and might
explain some of the ideas behind the current design:
Date: 26 NOV 1976 1439-EST
From: JF at CCA
Subject: RELEASE OF NEW DFTP
To: DFTP LIAISONS:
cc: ROTHNIE
A new version of DFTP is being installed at all sites. This
version is compatible at the command level for most users.
However, there are a number of extensions and changes in
relatively infrequently used parts of the system; people who
make extensive use of subdirectories (using the CONNECT command)
may find themselves particularly affected.
Documentation for the new version exists in both the old and
new versions of DFTP. In the old, it can be retrieved by the
following sequence:
@(O)DFTP
[ATTACHING]
*GET <<<COMMON>DFTP.NEW-MEMO
[OK]
*QUIT
In the new version:
@(N)DFTP
[ATTACHING]
*GET <<<COMMON>DFTP>NEW.DOC
(SXCFS: STAGING DATA FOR FILE = DFTP.COMMON.DFTP."<FILES">)
(SXCFS: STAGING DATA FOR FILE = DFTP.COMMON.DFTP."<FILES">)
{OK}
*QUIT
The new version of DFTP is distinguished by several
features:
1. Availability. New DFTP runs on ITS, SAIL, TENEX,
TOPS-10, and TOPS-20 systems; it is also being
implemented on MULTICS.
2. Capacity. New DFTP uses a mass store, an Ampex Terabit
Memory System (TBM). This device currently provides an
on-line capability of about 200 billion bits, expandable
up to 3.2 trillion (10**12) in the full configuration.
As a consequence, most users have had their allocations
increased. As another consequence, users may expect
noticeable delays when they first access data, as it is
moved from tertiary to secondary storage. These delays
may range from a few seconds to several minutes; they
will be signalled by a message like the one appearing in
the example above.
3. New storage structure. The new DFTP collects files for
a user into one or more large Datacomputer files. This
new organization is much more space-efficient than the
old; it should also serve to minimize delays for staging
from tertiary storage.
4. Extended functions. Several new features follow from
DFTP's new file organization:
a. File Sets. Commands which refer to files may now
specify a set of files in place of a single file,
by use of an asterisk in a file name field. This
operates like a "wild card", matching any value
in that field. For example,
*PUT FOO.*
(FOO.DOC)
(FOO.MAC)
(FOO.REL)
(FOO.SAV)
stores all four files in the user's directory
which have a first name of "FOO", with a single
command.
b. File version numbers. DFTP now maintains an
internal version number, so that several
different version of the same file may be kept
and retrieved individually.
c. DELETE, UNDELETE, and EXPUNGE. The effect of
DELETE is now revocable; until an EXPUNGE
command is executed, deleted files may be rescued
and returned to normal status. EXPUNGE should be
a fairly infrequent operation, used to reclaim
space when an allocation is filled with unwanted
files.
d. Increased directory information. The amount of
information kept with a file has been increased
significantly. DFTP now keeps a local write
date, a DFTP store date, file bytsize, length in
bytes, full-length file names, and a checksum.
This information contributes added convenience to
users. It also provides full-circle integrity
checking, with the same checksum computed and
checked throughout the file's handling by DFTP.
Full decscriptions of these and other aspects of the new DFTP
are contained in the document mentioned above.
∂06-Dec-76 1358 FTP:DEE at CCA APOLOGIES FOR 203 DATACOMPUTER AVAILABILITY
Date: 06 DEC 1976 1657-EST
From: DEE at CCA
Subject: APOLOGIES FOR 203 DATACOMPUTER AVAILABILITY
To: DATACOMPUTER USERS:, DFTP LIAISONS:, SEISMIC-USERS:,
To: DATACOMPUTER-STAFF:, ACCAT:, DDBS:
cc: DEE
DEAR USERS,
OUR APOLOGIES FOR THE LACK OF AVAILABILITY OF THE 203 DATACOMPUTER
DURING NORMAL BUSINESS HOURS LAST WEEK AND TODAY. WE HAVE BEEN AFFLICTED
BY TBM PROBLEMS AND ALSO PROBLEMS WITH OUR TENEX RP-02 DISKS AND ONE
MOMENTARY GLITCH IN OUR COMMERCIAL POWER SUPPLY. WE HOPE FOR GREATER
AVAILABILITY THE FUTURE.
DONALD EASTLAKE
PS: WHEN THE CCA-TENEX HOST IS UP INFORMATION ON DATACOMPUTER STATUS
IN NORMALLY AVAILABLE BY ICP'ING TO SOCKET 703 (OCTAL).
-------
∂16-Dec-76 1340 FTP:REM at MIT-MC (Robert Elton Maas ) CCA Datacomputer TBM, DFTP
Date: 16 DEC 1976 1639-EST
Sender: REM at MIT-MC
From: REM at MIT-MC (Robert Elton Maas )
Subject: CCA Datacomputer TBM, DFTP
To: LES at SU-AI
Message-ID: <[MIT-MC].20419>
You were inquiring as to my experience with DFTP. It looks
like it'll be quite a while before it is a reliable way to store and
retrieve data. As far as I know it hasn't lost data and not detected
it immediately (and this occurred during net FTP of data, not after
storage), but accessibility is pretty bad. For example, early this
morning I was doing a few transfers, and every so often it would just
hang forever. After 10 minutes of no response I flushed my core
image and tried again and it worked, about three such temporary
hangings, but around 4 or 5 am I tried to delete a subfile on TBM
and it hung forever not even verifying the name of the file I
wanted to delete, so finally I killed it and tried again, and again
it hung forever, finally I gave up and went to bed. Right now
on MC I am trying to get a directory of that file containing the
subfile I tried twice to delete, and for the past 1/2 hour it has
been "STAGING" the file, or sitting there doing nothing pretending
to be staging. Better stick to DART as main backup for awhile...
∂05-Feb-77 1519 REM DFTP and FTP
One pecularity, the triangle inequality is violated, it takes
longer to retrieve a file directly from cca to su-ai than it does to
first run DFTP on mit-mc and retrieve it from cca to mit-mc, then to
FTP it from mit-mc to su-ai.
Test case, retrieving a 3.5 k file...
direct cca to su-ai, 150 seconds, 815 baud
cca to mit-mc, 21 seconds, 6090 baud
mit-mc to su-ai, 26 seconds, 4900 baud
total 47 seconds, more than 3 times as fast than direct route, indicating
bugs in software when direct route is used (perhaps too-small message
size, bad network route, bad interrupt handling, bureaucracy imposing
lower datarate for su-ai, who knows??)
For short files, the overhead in telnetting to mit and logging in
and starting up DFTP and FTP is too much, but for long files it is
actually faster to do the two-step method via mit-mc.
∂05-Feb-77 1534 REM DFTP timing
I have noticed consistantly that DFTP cca to su-ai is in the range
of 800 to 1600 baud, whereas FTP mit-mc to su-ai is much faster and also
DFTP cca to mit-mc is also much faster. Speed doesn't seem to be much
affected by system load, when disk access is slowed down so much that
one minute of disk time takes 12 minutes (very heavy load) DFTP doesn't
seem to be much affected, but anyway since the maximum speed ever (zero
system load) is about 1600 baud (sometimes 1800 if very lucky) any variation
toward very-slower-dftp during heavy load is irrelevant.
This one experiment was just to get some numbers to quote, to
verify my observations. If you want I can conduct a couple additional
tests.
Note that su-ai to mit-mc FTP is considerably slower than mit-mc
to su-ai FTP, thus two-step ftp/dftp might not be advantageous when storing
files to cca. (Or at least the last time I noticed, it was slower. I griped
to people at both mit-mc and su-ai about difference in speed in FTP a year
ago and got various theories I have since forgotten. I guess I should
conduct a fullscale test in which the same file, a moderately large file,
is moved around in all possible directions several times to get spread of
timings:
SU-AI -- DFTP (PUT, GET) -- FTP (RETR, STOR)
MIT-MC -- DFTP (PUT, GET) -- FTP (STOR, RETR)
8 experiments, 3 times each perhaps.
∂05-Feb-77 1918 REM DFTP primer
See DFTP.PRI[1,REM] for primer on how to use DFTP, examples you
can try yourself and compare with what is shown in the file as
the "correct" echo and the "correct" resultant action from DFTP.
Some time you feel like experimenting with DFTP to get a feel for it,
list my DFTP primer and try all the examples, hopefully the primer and
examples hands-on will be sufficient that you can use DFTP.MRC[UP,DOC]
as a reference manual to find out anything else you need to know, or
ask an expert for more obscure info.
∂10-Feb-77 0657 FTP:JF at CCA User Support Contacts at the Datacomputer
Date: 10 FEB 1977 0958-EST
From: JF at CCA
Subject: User Support Contacts at the Datacomputer
To: DATACOMPUTER USERS:, DFTP LIAISONS:, SEISMIC-USERS:,
To: SPONSORED-RESEARCH-DIV-STAFF:, ACCAT:, DDBS:
CCA is expanding its user support activities for the Datacomputer. One
part of this expansion is the institution of a "Programmer of the Week"
-- a member of the Datacomputer staff will be responsible each week for
responding to user queries, suggestions and complaints arriving during
that week. Therefore, we have also instituted a standard address for
user contacts:
People who need help in using the Datacomputer should
- SNDMSG to HELP @ CCA, or
- call CCA (617) 491-3670, and ask for the
"Datacomputer Programmer of the Week"
We expect this procedure will promote uniform, fast and effective
response for users.
Jerry Farrell
Manager, User Support
-------
∂10-Feb-77 2315 REM via AMET DFTP speed
Several tests verify, GET command (CCA-TO-SUAI) is now much faster,
about 5000-8000 baud. PUT command (SUAI-TO-CCA) is still slow,
about 1300-2200 baud. I'm attempting to get them to fix that too...
∂07-Jun-77 0046 REM via AMET ∂07-Jun-77 0037 REM via AMET Bug still happening, my first try since giving up yesterday gave this:
To: LES, JBR
*ATTACH <<<SUAI>REM:
*DIRECTORY POX.*
**TERSE
(SXCX73: STAGING DATA FOR FILE = 560. DFTP.SUAI.REM.<FILES> TBM#6#1675240)
(SXCX73: STAGING CAT PGS FOR FILE = 1. DFTP.SUAI.REM.<FILES> TBM#6#1675856)
POX.CRU;1 24951(-8)
POX.EXP;1 384(-15)
(SXCX73: STAGING DATA FOR FILE = 56. DFTP.SUAI.REM.<FILES> TBM#6#1675800)
*TIME-TRANSFERS
*PUT POX.PLN
[OK]
IMP IO WITHOUT REQUEST FOR CONNECTION
UUO at user 412370
∂01-Dec-77 1814 BH via AMET proposed incompatible change to FTP
To: JBR, ME, LES
Based on a user complaint, I propose to make LPPN the default mode instead
of RPPN. This affects the interpretation of FTP commands this way:
command: GET FILE.EXT[PRJ,PRG]
mode local file written sent to host to be read
LPPN FILE.EXT[PRJ,PRG] FILE.EXT
RPPN FILE.EXT[alias] FILE.EXT[PRJ,PRG]
This will be of benefit to everyone except users of CMU, I think. Should
I just do it, or would you like to discuss it at the system meetiing?
∂28-Feb-78 0116 RAK Cutesies from MRC
As it happened, I chanced to do an FTP at ISI from here. When you start
your FTP, it says "Lookout! Here comes <filename>" When the transfer
is done it says "The End"
In addition, when you do a R HOST here, it is much, much more verbose.
Sometimes that may be useful. When you are trying to look at the names for
one you want to remember, it is very painful. All sorts of cute "unofficial"
abbreviations are included.
Les, it is hopeless, as you know, to explain or complain to MRC about things
like this. All I would get is a 300 line essay questioning my success and
explaining how lots of other hackers really want it that way. And it is
not overwhelmingly important, except that the FTP thing makes us look like
dumbos to outsiders (I mean, I guess I wouldn't mind if the messages were
funny. They're just dumb).
Essentially, what it means is that there is no way to protest an MRC decision on
even the most trivial thing because he makes it so agonizing to do so and then
refuses to do anything about it. Is that right?
Dick
P.S. I still can't do TELNET from my TI, but I haven't brought the terminal
in.