[Info-vax] RMS internals?
Rich Alderson
news at alderson.users.panix.com
Mon Aug 10 16:35:26 EDT 2009
glen herrmannsfeldt <gah at ugcs.caltech.edu> writes:
> I believe that there is also an FTP option specifically for 36 bit
> systems, but I don't remember how that works.
I think that you're thinking of the TOPS-20 specific appendix to RFC 959,
pp. 60-61. Although exactly the same kind of thing would work for other
page-oriented file systems, I don't believe that anyone else ever used this.
(Note that the "NLS" in the text is Doug Engelbart's "oNLine System", which
is part of (and/or ancestral to) Augment, his magnum opus.)
APPENDIX I - PAGE STRUCTURE
The need for FTP to support page structure derives principally from
the need to support efficient transmission of files between TOPS-20
systems, particularly the files used by NLS.
The file system of TOPS-20 is based on the concept of pages. The
operating system is most efficient at manipulating files as pages.
The operating system provides an interface to the file system so that
many applications view files as sequential streams of characters.
However, a few applications use the underlying page structures
directly, and some of these create holey files.
A TOPS-20 disk file consists of four things: a pathname, a page
table, a (possibly empty) set of pages, and a set of attributes.
The pathname is specified in the RETR or STOR command. It includes
the directory name, file name, file name extension, and generation
number.
The page table contains up to 2**18 entries. Each entry may be
EMPTY, or may point to a page. If it is not empty, there are also
some page-specific access bits; not all pages of a file need have the
same access protection.
A page is a contiguous set of 512 words of 36 bits each.
The attributes of the file, in the File Descriptor Block (FDB),
contain such things as creation time, write time, read time, writer's
byte-size, end-of-file pointer, count of reads and writes, backup
system tape numbers, etc.
Note that there is NO requirement that entries in the page table be
contiguous. There may be empty page table slots between occupied
ones. Also, the end of file pointer is simply a number. There is no
requirement that it in fact point at the "last" datum in the file.
Ordinary sequential I/O calls in TOPS-20 will cause the end of file
pointer to be left after the last datum written, but other operations
may cause it not to be so, if a particular programming system so
requires.
In fact, in both of these special cases, "holey" files and
end-of-file pointers NOT at the end of the file, occur with NLS data
files.
The TOPS-20 paged files can be sent with the FTP transfer parameters:
TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
Each page of information has a header. Each header field, which is a
logical byte, is a TOPS-20 word, since the TYPE is L 36.
The header fields are:
Word 0: Header Length.
The header length is 5.
Word 1: Page Index.
If the data is a disk file page, this is the number of that
page in the file's page map. Empty pages (holes) in the file
are simply not sent. Note that a hole is NOT the same as a
page of zeros.
Word 2: Data Length.
The number of data words in this page, following the header.
Thus, the total length of the transmission unit is the Header
Length plus the Data Length.
Word 3: Page Type.
A code for what type of chunk this is. A data page is type 3,
the FDB page is type 2.
Word 4: Page Access Control.
The access bits associated with the page in the file's page
map. (This full word quantity is put into AC2 of an SPACS by
the program reading from net to disk.)
After the header are Data Length data words. Data Length is
currently either 512 for a data page or 31 for an FDB. Trailing
zeros in a disk file page may be discarded, making Data Length less
than 512 in that case.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
news at alderson.users.panix.com --Death, of the Endless
More information about the Info-vax
mailing list