SALV - Salvager for the SITS file system.

build/misc.tcl

@@ -1634,6 +1634,10 @@ respond "*" ":cwd sits\r"
 respond "*" ":palx sits\r"
 expect ":KILL"
 
+# Salvager for the SITS file system.
+respond "*" ":palx salv\r"
+expect ":KILL"
+
 # TORTIS
 respond "*" ":midas;324 radia;_tortis\r"
 expect ":KILL"

build/timestamps.txt

@@ -1811,10 +1811,12 @@ reh/mmacro.51 198210111328.44
 rg/chess2.614 197705140751.33
 rjl/edit.memo 197509301913.38
 rjl/files.31 197201301710.18
+rjl/flopdf.10 197705111553.50
 rjl/logo.49 197303061208.18
 rjl/logops.70 197303061151.09
 rjl/lstops.11 197109150931.27
 rjl/musops.21 197302212116.23
+rjl/salvd.3 197512150856.09
 rjl/turops.67 197303061139.25
 rjl/vecops.1 197107261022.12
 rlb/fasdmp.124 197901090635.35
@@ -1904,6 +1906,7 @@ shrdlu/ts.twdemo 197110311544.38
 sits/-read-.-this- 197503032229.00
 sits/conven.3 197503051957.44
 sits/docum.66 197607010317.17
+sits/salv.175 197711241704.25
 sits/sitmac.6 197609212250.40
 sits/sits.119 197712281629.08
 sits/styi.207 197702231829.55

doc/rjl/salvd.3

@@ -0,0 +1,128 @@
+SALV, the SITS/LOGO File System Checker
+
+Introduction
+
+	The program called SALV is a utility program for the maintence of
+disks for the SITS/LOGO systems. Its main function is to provide a consitency
+check of the directory structure on the disks, but it also includes functions
+for initializing format and file structure, and copying disks in various ways.
+The purpose of this document is to aquaint the reader with both the theory
+and the operation of SALV, and in particular give him enough information
+to enable him to deal with both day-to-day file system maintence and the
+many special problems that can arise.
+
+The SITS File System
+
+	The SITS file system provides users of the SITS system with very flexible
+ways of maintaining disk files. It makes no attempt to impose any restrictions
+on the type and format of the data stored in the files, provided that that data
+can be represented as an ordered vector of 16 bit words. It does, however,
+impose a structure of 1directories0 in which files may be kept. That structure
+is a strictly inverted tree, that is, pointers from directories must always
+point downward in the structure. Also, no directory may be pointed at by
+more or less than one other directory, except in the special case of the
+1root0 directory, which no other directory points to. Now, we shall try to
+clarify this.
+
+The Notion of Directory
+
+	In the SITS file system, a directory is a vector of files and 
+inferior directories. The inferior directories may in turn contain
+directories. Each entry in the vector has a name and a type and possibly
+a version number. The entries are kept in alphabetical order by name, and
+when names are the same, in numerical order by version number. Each entry
+also contains a block descriptor which provides the disk addresses of zero
+or more blocks that are associated with the file or directory described
+by the entry. There are also two special entries at the beggining of each
+directory which we will discuss later.
+	At the very top of the directory structure of each disk is the special
+directory called the root. The main thing that is special about
+the root directory is that its disk address is predefined.
+The first block of the root directory of each logical disk resides on block 46 of that
+disk. All other information about what is where on any given disk
+can and must be determined by reading the root directory and
+following the tree structure downwards to the file or directory of
+interest.
+
+Files
+
+	A file is a vector of 8 bit bytes stored in blocks of 1024 bytes
+on the disk. Each byte has a number assigned to it called its 1address in the
+file0. Thus, the first byte of a file is byte 0, the last byte in the
+first block of a file is byte 1023, etc. A file has a length, which is the
+byte address of the last byte of the file; this length is not restricted
+to be a multiple of 1024, nor of 2.
+Files may in theory be up to
+2**25 (about 33.5 million) bytes long, but other restrictions reduce this.
+It is possible for there to be 1holes0 in the file
+these holes must start and end on file address which are a multiple of 1024,
+that is, on block boundaries. These holes are not particularly useful
+and we will attempt to avoid any futher discussion of them.
+	The directory entry for a file contains two pieces of information
+that describe the file: the file address of the first byte which is
+1not0 in the file, and an encoded list of the disk block addresses
+where the bytes of the file reside.
+	In addition to the name and version number the file entry also
+contains the date and time that the file was created. The file
+entry also potentially contains an 1access list0 which would
+restrict access to files to specified users, but neither LOGO nor
+SITS support this feature.
+
+Operation of the SALV Program
+
+	Now that the reader (hopefully) has a general idea of what the
+file system looks like, we will switch topics drascially and discuss
+the operation of the SALV program, particularlly it's user interaction.
+	The SALV program currently can only be run standalone, that is,
+it cannot be run under the SITS timesharing system since it does
+direct hardware disk operations, and also because the operation of
+SITS could cause the file structure to become inconsistent.
+SALV can either be loaded with RUG or directly from paper tape.
+Its starting address is 1000, and it can be safely restarted at
+(almost) any time. Restarting SALV is a perfectly valid way to
+abort an operation. Generally, SALV is either waiting for command
+input from the teletype or running performing some function
+commanded from the teletype. It ignores typing while it is
+performing a function. All functions are initated with one character
+commands. Most functions also accept preceeding arguments or
+require inputs. Some of the more drastic functions require
+confirmation after they have described themselves. At
+any time SALV is waiting for an input character the character
+<control>Z may be typed which will cause SALV to execute
+a BPT instruction which should in turn cause RUG to be called,
+if SALV was loaded by RUG. If SALV is then proceeded (type <esc>P
+to RUG) you will reenter the typein wait you just left.
+SALV can also be restarted (type <esc>G to RUG) to go
+back to the beginning. The following commands take a 1 digit
+number preceeding the command as input. The number specifies
+which disk the command is to effect:
+
+	C	Check a disk. The main function of SALV.
+
+	I	Initialize a disk.
+
+	<control>F	Format a disk.
+
+The following commands take no preceeding input:
+
+	<control>U	Copy logigical disks 0 and 1 to logical disks
+			2 and 3, i.e. copy the fixed platter up to the
+			removable platter on double density drives.
+
+	<control>D	As <control>U, but copy 2 and 3 to 0 and 1, i.e.
+			copy removable down to fixed.
+
+	<control>C	Asks for two disk numbers and copies one logical
+			disk to another logical disk.
+
+(A note about the meaning of "logical disk": currently the only type
+of disk supported by LOGO/SITS/SALV/RUG is the RK11 compatible units
+made by DEC and others. The disk DEC makes has one disk per drive,
+and each disk has 203. tracks; this corresponds to the standard
+"logical disk". The drives made by Caleus and Wangco and supported by
+IMS disk controllers have 2 disks in each drive, one fixed and one
+removeable. Most of these have 203. tracks on each pyhsical disk
+and thus coorespond to 2 logical disks, but there are drives that
+have 406. tracks on each disk, and in this case, currently, each
+pyhsical disk cooresponds to 2 logical disks, and therefore there
+are 4 logical disks per drive. Clear?)

src/rjl/flopdf.10

@@ -0,0 +1,63 @@
+SMSCSR==177200		;THE CSR FOR THE SMS TO PDP11 INTERFACE
+SMSDBF==SMSCSR+2	;THE DATA BUFFER BYTE
+SMSCMD==SMSDBF+2	;THE COMMAND BUFFER BYTE
+SMSLGT==SMSCMD+2	;LIGHT REGISTER
+SMSBRV==270		;TRAP VECTOR ADDRESS
+SMSTV==SMSBRV
+CLKBRV==100	;CLOCK TRAP ADDRESS
+SMSPRM==173000	;PROM ADDRESS
+SMSPRE==173376	;LAST PROM ADDRESS (CONFIGURATION WORD)
+ SMS60H==1	;IF THIS BIT IS ONE, MACHINE IS 60HZ, ELSE 50HZ
+SMSRST==0	;RESET COMMAND, SECOND BYTE IGNORED
+SMSSEK==1	;SEEK, OR WITH DISK DRIVE_3, SECOND BYTE TRACK ADDRESS
+SMSRED==2	;READ, OR WITH DISK DRIVE_3 AND:
+ SMSDTB==100	 ;DISK TO BUFFER BIT
+ SMSBTH==200	 ;BUFFER TO HOST BIT
+		  ;SECOND BYTE ON READ IS SECTOR
+SMSRID==3	;READ NEXT SECTOR ID, OR WITH DISK DRIVE_3, SECOND BYTE IGNORED
+SMSWRT==4	;WRITE, OR WITH DISK DRIVE_3 AND:
+ SMSBTD==100	 ;BUFFER TO DISK
+ SMSHTB==200	 ;HOST TO BUFFER
+		  ;SECOND BYTE ON WRITE IS SECTOR
+SMSWRD==5	;WRITE WITH DELETED DATA MARK, OTHERWISE SAME AS WRITE
+SMSFMT==6	;FORMAT THE TRACK THE HEADS ARE OVER
+		 ;OR WITH DISK DRIVE_3, SECOND BYTE IS TRACK ADDRESS TO WRITE ON DISK
+SMSSTS==7	;READ STATUS, OR WITH DISK DRIVE_3, SECOND BYTE IGNORED
+
+;STATUS BITS IN CSR
+SMSERR==100000	;ERROR IN OPERATION
+SMSRSB==40000	;RESET BIT
+SMSPWR==4000	;POWER ON DISK DRIVES
+SMSCLE==2000	;CLOCK INTERUPT ENABLE
+SMSST1==1000	;STAT ID BIT 1
+SMSST0==400	;STAT ID BIT 0
+SMSDNE==200	;DONE
+SMSINT==100	;INT ENABLE
+SMSBSY==40	;BUSY
+SMSCMW==20	;WAITING FOR A COMMAND BYTE
+SMSDDR==10	;DATA DIRECTION
+SMSFDO==4	;FDC ON
+SMSXFW==1	;WAITING FOR XFR
+
+;STATUS BITS IN STATUS BYTE
+;COMMAND STATUS
+SMSITA==2	;INVALID TRACK ADDRESS
+SMSISA==4	;INVALID SECTOR ADDRESS
+SMSIBS==10	;INVALID BUFFER SPEC
+;DISK DRIVE STATUS
+SMSDNR==1	;DRIVE NOT READY
+SMSDUS==2	;DRIVE UNSAFE
+SMSDWP==4	;DRIVE WRITE PROTECTED
+SMSNAM==10	;NO ADDRESS MARKS FOUND
+SMSSIP==40	;SEEK IN PROGRESS
+;OPERATION STATUS
+SMSRWA==1	;READ/WRITE ABORTED
+SMSHPE==2	;HEAD POSITIONING ERROR
+SMSDAM==4	;DATA ADDRESS MARK MISSING
+SMSDOV==10	;DATA OVERRUN
+SMSSUR==20	;SECTOR UNRECOVERABLE
+SMSCRC==40	;CRC ERROR
+SMSRWC==100	;READ/WRITE COMPLETE
+SMSDDR==200	;DELETED DATA READ
+
+