.NONUMBER
.LM 0
^PY^-
.PAGE SIZE 58,85
.LM 10
.RM 75
.NO FILL
.NO JUSTIFY
#
.SKIP 5
.CENTER
The RSX Multi-Tasker
.CENTER
November, 1986
.SKIP
.CENTER
^IS144^G"All the News that Fits, We Print"^IS204^G
.SKIP
.CENTER
Fine Realtime Commentary Since 1975
.SKIP 6
.CENTER
^&Table of Contents\&
.SKIP 2
.TAB STOPS 60
The Editor's Corner RSX-1
Free PCs - Get 'Em While They Last RSX-1
Submitting Articles to the Multi-Tasker RSX-3
Answer to Last Month's Quiz RSX-3
And That's The Way Things Are RSX-4
The Bag of Tricks: MACRO-11 RSX-4
RMDEMO Enhancements RSX-6
Rebuilding Device Drivers RSX-9
Free Software RSX-13
Files-11 On Disk Structure Specification RSX-14
.JUSTIFY
.FILL
.PAGE
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT The Editor's Corner
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
#
.SKIP 5
.AUTOPARAGRAPH
.CENTER
^&The Editor's Corner\&
.SKIP
.CENTER
Bruce R. Mitchell
.SKIP 2
By the time you read this, the Fall 1986 Symposium will be over.
This issue is being submitted to print in late September, so the first
reports you'll be reading on the Fall Symposium will be appearing in the
December issue.
This issue marks the launching of a new, ongoing education project
for the RSX SIG. Over the next year, as space permits, the Multi-Tasker
will reprint some of the 'landmark' RSX technical papers and articles from
the past. This series will include the original ACM paper on the RSX operating
system by Dave Cutler, the exposition on SAV by Paul Bezeredi, the topological
walk to an ODL by John Covert, the mathematics of RSX-11 by Ralph Stamerjohn,
and other fundamental RSX articles which are now difficult to find. This
month's article is the Files-11 disk specification.
There are also new articles for your enjoyment and edification. There
are patches to RMD to enhance the functionality and correct the worst-case
POOL statistics loss. There is an article dealing with the eternal problem
of adding devices already present in a system without doing a complete SYSgen.
There is a short article dealing with free software
(although I rather tend to think it deals with system security). And there's
a reminder in the Bag of Tricks about a PDP-11 architecture 'feature' we
sometimes tend to forget.
The editor wishes to thank each and every respondent to the call for
more articles. Keep those articles coming; I've got a little something for all
submittors. And don't forget to send in your entries for the puzzle contest
from last month's issue. They're beginning to roll on in now, but not as many
as I expected, so keep them coming.
And now, ladies and gentlemen, here's this month's dollop of food for
thought.
.TEST PAGE 5
.SKIP 2
.CENTER
----- Free PCs - Get 'Em While They Last -----
No doubt many of you wonder how the Multi-Tasker is published each
month. Currently, it goes something like this:
.SKIP
- Editor accepts manuscripts up to 3rd week of the month
.BREAK
- Editor types manuscripts in to big RUNOFF file
.BREAK
- Shortly before deadline, editor makes frantic final edits
.BREAK
- Editor runs out final copy on letter-quality printer
.BREAK
- Editor (often Express) mails in final copy to DECUS HQ
.BREAK
- Editor breathes huge sigh of relief
.BREAK
- DECUS HQ adds article headers and page numbers
.BREAK
- DECUS HQ sends final copy to printers
And that's how the Multi-Tasker gets published every month. The
Communications Committee, however, has a new and different idea. The idea
goes something like this:
.SKIP
- DECUS buys each newsletter editor a PC,
.BREAK
####################################a printer,
.BREAK
####################################a 2400 baud modem,
.BREAK
####################################and pays for a phone line.
.BREAK
- Contributors call the PC and KERMIT / EDT / DECnet in articles
.BREAK
- Editors prepare newsletters in a standard format using PCs
.BREAK
- Editors dial up a DECUS VAX and KERMIT / DECnet in newsletters
Sounds good, no? No doubt it sounds very good in some quarters.
Editors would have a Rainbow or Professional to play with when not
sending out the newsletters. And the cost is not actually very high; if the
equipment costs $2,500 per editor, over 23 newsletters the cost is
$57,500. Plus phone line installation and ongoing expenses, of course.
But from whence cometh this money? Newsletter subscription profits?
Probably not. For argument, let's say it comes out of symposia fees. That's
the biggest moneymaker. Attendance is in the 6,000 range, times 2 per year.
That means attendees pay an extra $5 for this project.
If true ... and this is only one project ... ever wonder why
symposium registration fees keep going up? Five bucks here, five bucks
there ... it does add up.
Now, with DECUS purportedly cutting expenses all over, some thought
leads to a few interesting questions.
.SKIP
Is standardization of newsletter formats necessary?
.BREAK
Is standardization of newsletter formats even desirable?
.BREAK
Will newsletter subscriptions increase as a result?
.BREAK
Will this reduce paid manpower which gets the newsletters out?
.BREAK
^IS144^GHas this project been reviewed by a disinterested
member panel?^IS204^G
.BREAK
Would this money be better spent elsewhere?
Little perks for volunteers are fine. Volunteers make DECUS run.
But is this project necessary? Or desirable?
^IS144^GThis^IS204^G editor doesn't think so.
Maybe ^IS144^Gyou^IS204^G, the members-at-large, don't
think so either. If not, you ^IS144^Gcan^IS204^G do something
about it. Write to Bob Curley. He's on the Board of Directors. He's
spearheading a project to improve communications between the membership and
the leadership. He's an end user. He'll listen.
.SKIP
Robert F. Curley
.BREAK
Department of Radiation Therapy
.BREAK
University of Pennsylvania
.BREAK
Room 410
.BREAK
133 South 36th Street
.BREAK
Philadelphia, PA
.BREAK
19104-3246
Write now. Don't put it off or it will never get done. Tell him
that you support this project or don't support it. Tell him that you like
the way DECUS is going or that you don't like it. Tell him that you get your
money's worth from symposia. Tell him that you don't
attend symposia because they're too expensive. Tell him that you don't
care. But do tell him something.
.TEST PAGE 5
.SKIP 2
.CENTER
----- Submitting Articles to the Multi-Tasker -----
Please do submit machine readable media when it's possible.
RX01, RX02 or RX50 diskette, or 800/1600 BPI 9 channel magtape are best.
Any format is acceptable except ROLLIN, PRESRV or VMS backup. ANSI, BRU and DOS
FLX formats are well-liked by the Editor's tape drive.
Submissions which aren't machine readable take longer to get into
print. The editor is lazy and types mass quantities only once a month when
progress reports are due.
If you preformat a submission in RUNOFF format, please set
left margin 10, right margin 75, and when changing margins use
incremental changes rather than absolute. The editor blesses you for
the consideration.
Send all submissions to:
.SKIP
.NO FILL
.NO JUSTIFY
Bruce R. Mitchell
Machine Intelligence and Industrial Magic
PO Box 816
Byron, MN 55920
.JUSTIFY
.FILL
.TEST PAGE 5
.SKIP 2
.CENTER
----- Answer to Last Month's Quiz -----
In the RSX Brain Teaser. But you'll have to ferret it out yourself.
.TEST PAGE 5
.SKIP 2
.CENTER
----- And That's The Way Things Are -----
_... this month in Pool Lowbegone, where
all the Digital sales reps sell strong, all the IBM sales reps are
good-looking, and the RSX SIG is above average.
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT The Bag of Tricks
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 6
.CENTER
^&The Bag of Tricks: MACRO-11\&
.SKIP
.CENTER
Bruce R. Mitchell
.CENTER
Machine Intelligence and Industrial Magic
.CENTER
PO Box 816
.CENTER
Byron, MN###55920
.SKIP
From time to time, assembly language programmers tend to find
themselves in situations where they are climbing the walls in search of a
program fault. This is sometimes due to an insufficient knowledge of PDP-11
architecture, in which the programmer
^IS144^Gexpects^IS204^G the machine to do something it
is ^IS144^Gnot^IS204^G supposed to do.
There is one peculiarity in the PDP-11 architecture that has probably
been encountered accidentally by more programmers than any other, and we're
going to take a look at it this month.
Examine the following segment of code, which the programmer
intended to read all the logical blocks on a disk, one at a time:
.SKIP 2
.NO FILL
.NO JUSTIFY
CLR READPB+Q.IOPL+6 ; Clear high word of LBN 2word
CLR READPB+Q.IOPL+8. ; Set up for disk LBN 0
10$: DIR$ _#READPB ; Read the next logical block
TSTB IOSTAT ; Did the read succeed?
BMI 20$ ; If not, go process the error
... processing of disk block information ...
INC READPB+Q.IOPL+8. ; Bump the LBN doubleword by 1
ADC READPB+Q.IOPL+6 ; Add carry, for real big files
BR 10$ ; And go look at the next block
.JUSTIFY
.FILL
.SKIP
When this code is tested, it runs fine on all disks the programmer
cares to try. Six months later, however, a site licensed for
the program containing this code complains that the program never finishes.
"Those idiots are doing something wrong," thinks the programmer as
he flies out to check out the problem. "If users would just read the
documentation! Oh well, nothing like a few more frequent flyer miles."
On site, the programmer checks out the task with various disks.
The task runs fine. "There's something wrong with your data!", he chortles
gleefully, and leaves. As he goes out the door, the site's VP-Engineering
is already having a nice chat with his Legal Department.
Let us gloss over a short but painful episode in the programmer's
career. The upshot of it is that he returns on the next plane.
Back on site, he discovers that the task runs fine on small disks,
but appears to loop forever when procesing large disks. The symptom is that
the program never ends up at 20$ with error code IE.BLK, which is
expected when attempting to read past end-of-disk.
It loops forever on big disks. But little disks work just fine.
Why does this problem occur? If you already know the answer, you
can skip on to the next article. If you don't, this may be an eye-opener
and cause you to rewrite some of your own code.
The programmer expected the INC instruction to set the carry bit
at block number 177777 (65,535) when BLKADD+2 rolled over to 0. The carry
bit would then be added to the high word of BLKADD, making the doubleword
(1,0) or 65,536. This is a common expectation; it is, however, incorrect.
The PDP-11 INC and DEC instructions ^IS144^Gdo not^IS204^G set
the carry bit.
It is now evident why the program runs on "small" disks. It works
correctly for any disk smaller than 65,536 blocks. On larger disks, it
cycles through blocks 0 to 65,535 repeatedly.
The fix? Replace the INC instruction with ADD _#1,
in cases
where it is important that the carry bit be set correctly.
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT RMDEMO Enhancements
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 6
.CENTER
^&RMDEMO Enhancements\&
.SKIP
.CENTER
John L. Newcomb
.CENTER
Hallmark Cards, Inc.
.CENTER
25 Bacon Road
.CENTER
Enfield, CT 06082
.SKIP
The time has come. I have procrastinated for as long as I can. The guilt
is too much to bear. After many years of benefiting from DECUS supplied
software, I am ready to offer a token of our appreciation: Enhancements
for RMD.
RMD has two display pages (I and M) that contain information about
mass storage devices. By default, RMD chooses these devices by following the
DCB chain, although at build time the user may specify any or all devices via
global patches in the RMD build file.
At runtime, whenever you desire RMD to display information on a
device that is not one of the default devices, you must change the designation
with the DEVICEx= command. This must be done each time RMD is invoked.
I'm sure this is as annoying to you as it is to me. Changing the default
devices by rebuilding RMD each time is not a viable alternative. The larger
the number of devices SYSgenned into each system just aggravates the problem.
The changes I have made to RMD offer a solution to this problem. I have
tested the modifications on RSX-11M+, versions 2.1D and 3.0B. Because I
have used the DEC supplied GIN$ directive, these changes should work on
any RSX that has the GIN$ directive available.
After applying the SLP files listed below and rebuilding, RMD displays
information on any mass storage device that has a local or global assignment to
the mnemonics DV0: thru DV5: . The mnemonics DVx: correspond to the RMD DEVICEx
command. A local assignment for a terminal running RMD overrides a global
assignment. We make global assignments in our system startup file and then
users may make their own local assignments.
For any RMD 'DEVICE' that does not have a corresponding DV:
assignment, RMD displays the information for the default device. This is
also the case for 'invalid' assignments such as 'ASN TT4:=DV2:'. I am not
aware of any device conflict in using the DV: mnemonic. If there is a
conflict, any mnemonic may be substituted in the SLP file for the RMDXCM.MAC
module and then used in ASN statements.
Users can now invoke RMD without having to change device designations
each time.
There have been several inquiries published requesting a fix to RMD
to retain the 'worst case POOL statistics' when switching pages. I plead
guilty to having the fix (as simple as it is) for a long time (say since M
V3.2 days). DEC has also come up with a 'fix' for version 3.0, so if you have
the problem and are running any system from M V3.2 to M+ V2.1, inclusive, do
the following:
In the module MDCOM.MAC, delete the following lines:
.SKIP 2
.NO FILL
.NO JUSTIFY
$MDWPL::.WORD 0 ; WORST CASE LARGEST POOL FRAGMENT
$MDWPT::.WORD 0 ; SMALLEST POOL HAS GONE TO
$MDWPF::.WORD 0 ; MOST NUMBER OF FRAGMENTS SO FAR
.JUSTIFY
.FILL
.SKIP
In the module RMDXCM.MAC, insert the above lines deleted from the
module MDCOM.MAC. Then pick-up with step 2 below.
Do the following steps for the source modules you have changed. The
source files are in [14,10].
.LIST
.LE
Apply the following SLP patches to the appropriate source.
.LE
Assemble the module. The Macro command line may be obtained by examining the
file [14,24]RMDASM.CMD . If you use the command lines from the file don't
forget to make the assignments for IN:, OU:, and LI: .
.LE
Replace the object files in [1,24]RMD.OLB using the commands:
.SKIP
SET /UIC=[1,24]
.BREAK
LBR RMD.OLB/-EP/RP=[14,10]module name,module name,etc
.LE
Rebuild RMD using 'TKB @RMDBLD'.
.LE
VMR REMove the old task and VMR INStall the new task if necessary.
.LE
REMove the old task and INStall the new task in the running system if necessary.
.END LIST
Here are the SLP patches to be applied to RMD source file
[14,10]RMDEMO.MAC:
.SKIP 2
.NO FILL
.NO JUSTIFY
RMDEMO.MAC/AU=RMDEMO.MAC
-/SCPAD/,,/;JLN/
GL.BUF: .BLKW 6 ; GLUN$ BUFFER
GN.BUF: .BLKW 6 ; GIN$ BUFFER
-/.MCALL/,,/;JLN/
.MCALL GLUN$S,GIN$S
-/40$:/,,/;JLN/
GLUN$S _#$DLUN, _#GL.BUF ; GLUN$ on TI:
BCS EXJ ; Skip, GLUN$ failed
#
; This loop handles global assignments of type DVnn:
#
CLR R0 ; Counts DV units
CLR R1 ; RMD table offset
MOV _#6, R2 ; 6 units max
#
LP: GIN$S _#GI.GAS, _#GN.BUF, _#6, _#"DV, R0, _#0, _#0
BCS 100$ ; Skip, GIN$ failed
#
BIT _#DV.DIR, GN.BUF+4 ; Directory device?
BEQ 100$ ; If not, don't do it
#
MOV GN.BUF, $MDDEV(R1) ; Load device name
MOVB GN.BUF+2, $MDDEV+2(R1) ; Load unit number
#
100$: INC R0 ; Do next DV unit
ADD _#6, R1 ; Point at next entry
SOB R2, LP ; And loop until done
#
; This loop handles local assignments of type DVnn:
#
CLR R0 ; Counts DV units
CLR R1 ; RMD table offset
MOVB GL.BUF+G.LUNU, R3 ; Load TI: unit _#
MOV _#6, R2 ; 6 units max
#
LP2: GIN$S _#GI.GAS, _#GN.BUF, _#6, _#"DV, R0, _#"TT, R3
BCS 200$ ; Skip, GIN$ failed
#
BIT _#DV.DIR, GN.BUF+4 ; Directory device?
BEQ 200$ ; If not, don't do it
#
MOV GN.BUF, $MDDEV(R1) ; Load device name
MOVB GN.BUF+2, $MDDEV+2(R1) ; Load unit number
#
200$: INC R0 ; Do next DV unit
ADD _#6, R1 ; Point at next entry
SOB R2, LP2 ; And loop until done
#
EXJ:
/
.JUSTIFY
.FILL
.SKIP
And here are the SLP patches to be applied to RMD source file
[14,10]RMDXCM.MAC:
.SKIP 2
.NO FILL
.NO JUSTIFY
RMDXCM.MAC/AU=RMDXCM.MAC
-/$MDDEV:/,.+12,/;JLN/
$MDDEV::.ASCII /DV/ ; Device name
.WORD 0 ; Unit number
.WORD 0 ; Device UCB address
.ASCII /DV/
.WORD 1, 0
.ASCII /DV/
.WORD 2, 0
.ASCII /DV/
.WORD 3, 0
.ASCII /DV/
.WORD 4, 0
.ASCII /DV/
.WORD 5, 0
/
.JUSTIFY
.FILL
.SKIP 2
^IS144^GThe patches described by John won't work on
RSX-11S/M; GIN$ isn't available. However, for S/M, the same effect is
available via ALUN$, then GLUN$ to DVnn: on a fake LUN; much the same
information is returned. Coding is left as an exercise for the
reader. --- The Editor^IS204^G
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT Rebuilding Device Drivers
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 6
.CENTER
^&Rebuilding Device Drivers\&
.SKIP
.CENTER
Gerald Burgess
.CENTER
McDonnell Douglas
.CENTER
PO Box 2637
.CENTER
Garden Grove, CA###92642-2637
.SKIP
Here is a nifty little command file I have found quite useful when
installing foreign devices that emulate DEC devices.
Recently I was adding an SI 9761 disk drive to a PDP-11/70 which
already supported DEC RM03s. Both devices require the use of the DR device
driver. One of the RM03s is my boot device and thus DRDRV is loaded
at VMR time. I was therefore looking at yet another SYSGEN.
Instead, I performed section H of SYSGEN, wrote and ran
this command file. The new device driver is loaded and brought online during
system startup. The system is now up and running with a DEC RM03 system disk
and an SI 9761 data disk.
In the event you need to add a DEC emulated device like I did,
here is a sample execution of "RENAMEDRV.CMD" :
.SKIP 2
.NO FILL
.NO JUSTIFY
>@RENAMEDRV
RENAMEDRV -- Cmd file to rename a device driver
>* Enter new driver name [S: R:2-2]: QA
>* Create new driver ? [Y/N]: Y
>* Assemble new driver ? [Y/N]: Y
>* Build new driver ? [Y/N]: Y
>* Enter old driver name [S: R:2-2]: DR
>* Enter old driver code filename [S: R:5-5 D:"DRDRV"]: DR
>* Enter old driver database filename [S: R:5-5 D:"DRTAB"]: DR
>* Enter new driver code filename [S: R:5-5 D:"QADRV"]: QA
>* Enter new driver database filename [S: R:5-5 D:"QADRV"]: QA
#
RENAMEDRV -- Creating QATAB.MAC
DR1:[11,10]QATAB.MAC;1 336 lines
[EOB]
RENAMEDRV -- Creating QADRV.MAC
DR1:[11,10]QADRV.MAC;1 1313 lines
[EOB]
RENAMEDRV -- Making device assignments
RENAMEDRV -- Assembling driver
RENAMEDRV -- Building driver
RENAMEDRV -- STOP
@
.JUSTIFY
.FILL
.SKIP
And here is the source text for the indirect command file itself:
.SKIP 2
.NO FILL
.NO JUSTIFY
_.; RENAMEDRV -- Cmd file to rename a device driver
_.; Gerald Burgess May 1986
_.;
.ENABLE GLOBAL
.ENABLE SUBSTITUTION
.ENABLE QUIET
.OPEN TI:
.DATA RENAMEDRV -- Cmd file to rename a device driver
.CLOSE
.ASKS [2:2] NEW Enter new driver name
.ASK EDT Create new driver
.ASK ASM Assemble new driver
.ASK BLD Build new driver
.SETL ASMBLD ASM!BLD
.SETL ANY ASMBLD!EDT
.IFF ANY .GOTO DONE
.IFF EDT .IFT ASMBLD .GOTO ASMBLD
.ASKS [2:2] OLD Enter old driver name
.SETS OLDDV OLD+"DRV"
.SETS OLDTB OLD+"TAB"
.SETS NEWDV NEW+"DRV"
.SETS NEWTB NEW+"TAB"
.ASKS [5:5:OLDDV] OLDDV Enter old driver code filename
.ASKS [5:5:OLDTB] OLDTB Enter old driver database filename
.ASKS [5:5:NEWDV] NEWDV Enter new driver code filename
.ASKS [5:5:NEWTB] NEWTB Enter new driver database filename
.SETS OLDDV OLDDV+".MAC"
.SETS OLDTB OLDTB+".MAC"
.SETS NEWDV NEWDV+".MAC"
.SETS NEWTB NEWTB+".MAC"
.OPEN RENAMEDRV.EDT
.DATA S/'OLD'/<>/W/NOTYPE
.DATA S/<><>/<>DR/W/NOTYPE
.DATA S/<>IVE/DRIVE/W/NOTYPE
.DATA S/AD<>ESS/ADDRESS/W/NOTYPE
.DATA S/<>Y/DRY/W/NOTYPE
.DATA S/A<>/ADR/W/NOTYPE
.DATA S/.EN<>/.ENDR/W/NOTYPE
.DATA S/S3.<>L/S3.DRL/W/NOTYPE
.DATA S/<>/'NEW'/W/NOTYPE
.DATA EX
.CLOSE
.OPEN TI:
.DATA RENAMEDRV -- Creating 'NEWTB'
.CLOSE
EDT 'NEWTB'='OLDTB',RENAMEDRV.EDT
.OPEN TI:
.DATA RENAMEDRV -- Creating 'NEWDV'
.CLOSE
EDT 'NEWDV'='OLDDV',RENAMEDRV.EDT
.IFF ASMBLD .GOTO DONE
_.ASMBLD:
.OPEN TI:
.DATA RENAMEDRV -- Making device assignments
.CLOSE
ASN SY:=LB:
.WAIT ASN
ASN SY:=IN:
.WAIT ASN
ASN SY:=OU:
.WAIT ASN
ASN SY:=LS:
.WAIT ASN
_.ASM:
.IFF ASM .GOTO BLD
.OPEN TI:
.DATA RENAMEDRV -- Assembling driver
.CLOSE
SET /UIC=[11,10]
.WAIT SET
.OPEN 'NEW'MC.MAC
.DATA LD$'NEW'=0 ; ** 'NEW'DRV IS LOADABLE **
.CLOSE
PIP 'NEW'MC.MAC/AP=RSXMC.MAC
.WAIT PIP
.OPEN [200,200]'NEW'DRVASM.CMD
_.DATA ;
_.DATA ; 'NEW'DRVASM.CMD -- Loadable 'NEW': driver command file
_.DATA ;
_.DATA ; Created on '' at ''
_.DATA ;
_.DATA OU:[11,24]'NEW'DRV,LS:[11,34]'NEW'DRV/-SP=-
_.DATA IN:[1,1]EXEMC/ML,[11,10]'NEW'MC/PA:1,'NEW'DRV
_.DATA OU:[11,24]'NEW'TAB,LS:[11,34]'NEW'TAB/-SP=-
_.DATA IN:[1,1]EXEMC/ML,[11,10]'NEW'MC/PA:1,'NEW'TAB
.CLOSE
SET /UIC=[11,24]
.WAIT SET
.IFNINS ...MAC INS $MAC
.IFNINS ...MAC INS $MACFSL
MAC @[200,200]'NEW'DRVASM
_.BLD:
.IFF BLD .GOTO DONE
.OPEN TI:
.DATA RENAMEDRV -- Building driver
.CLOSE
SET /UIC=[1,54]
.WAIT SET
.OPEN [200,200]'NEW'DRVBLD.CMD
_.DATA ;
_.DATA ; 'NEW'DRVBLD.CMD -- Loadable 'NEW': driver command file
_.DATA ;
_.DATA ; Created on '' at ''
_.DATA ;
_.DATA OU:[1,54]'NEW'DRV/-MM/-HD,SY:[1,34]'NEW'DRV/SH/-SP,-
_.DATA OU:[1,54]'NEW'DRV=SY:[11,24]'NEW'DRV,SY:[11,24]'NEW'TAB,-
_.DATA SY:[1,54]RSX11M.STB/SS, LB:[1,1]EXELIB/LB
_.DATA /
_.DATA STACK=0
_.DATA PAR=DRVPAR:120000:20000
_.DATA /
.CLOSE
.IFNINS ...TKB INS $TKB
.IFNINS ...TKB INS $TKBFSL
TKB @[200,200]'NEW'DRVBLD
_.DONE:
.OPEN TI:
.DATA RENAMEDRV -- STOP
.CLOSE
.EXIT
.JUSTIFY
.FILL
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT Free Software
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 15
.SKIP 6
.CENTER
^&Free Software\&
.SKIP
.CENTER
Justin L. Hewser
.CENTER
Nocturnal Aviation Software
.CENTER
Aerial Piracy Division
.CENTER
Somewhere in California
.SKIP
This article was inexplicably left out of the last
three Multi-Taskers. After a midnight visit to the Multi-Tasker offices
and an investigation of the wastebasket and personal files,
I was able to convince the editor that it should be printed as
a public service. --- Justin
.SKIP
^IS144^GThere must have been a mistake somewhere at the
printers. I'm really quite sure I told them to print this, not
burn and lose it. --- The Editor^IS204^G
.SKIP
The high cost of software, whether from DEC or other source, is
a factor which inhibits productivity at many sites. I don't know about
^&your\& site, but ours can barely keep up with the cost of keeping
M-Plus and Fortran 77 on contract. We can't even afford to think about things
like full A-to-Z, DECnet or Datatrieve. Far too expensive to buy, too
expensive to maintain.
Nocturnal Aviation works on a shoestring budget, I should have
mentioned. We're now seriously looking at our first hardware upgrade in several
years ... except that we really like the RK05s, and are still not so sure
about these new technology RK06 drives. Lots of mass storage isn't
everything, right?
Back to the subject at hand. The other day, one of
my Mongolian DECUS friends shipped me some tapes to swap for copies
of old RSX SIG tapes. Never having seen "Yak Watch" tapes before, I
figured I'd check them out before use.
I checked them out with PIP, FLX, BRU, and a tape cracker I wrote
myself.
You can imagine my surprise
^IS144^G(and ill-concealed glee, no doubt -- Ed.)^IS204^G when
these tapes turned out to contain backups of his entire
system. "Well, what a surprise!" sez I. "Oh look, here's
a big mailing list, here's the DECnet source, here's
Minitab, here's SORT-11, and ...." Anyway, you get the idea.
It wouldn't have been fair to ship the tapes back, because then
he wouldn't have the SIG tapes he wanted. So I just made backups of
the important things, in case he might ever lose them and
need backup copies. And then I copied the SIG tapes right on top of those
old system backups.
Like many other sites, we make frequent backups to
tape. And while we do believe in off-site storage of backups, we don't think
that our friends should have to do it for us. So when we send out old tapes for
copying of SIG tapes and the like, we use a bulk eraser on all
tapes before they go out the door. That way we save ourselves and our
friends a lot of trouble.
Well, that's all very interesting, but not really related to
Free Software. And I see I'm running out of space for this article,
not to mention that there's a lot of loud pounding and yelling to "open up"
at the door of the computer room, so perhaps we'll continue this discussion
of Free Software some other time.
^IS144^G(A word to the wise should be
sufficient -- Ed.)^IS204^G
.COMMENT
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT Files-11 On Disk Structure Specification
.COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.COMMENT
.TEST PAGE 16
.SKIP 6
.CENTER
^&Files-11 On Disk Structure Specification\&
.SKIP
.CENTER
Digital Equipment Corporation
.CENTER
Maynard, MA
.SKIP
^IS144^GThis is the first in a series of reprints of landmark
RSX articles and technical papers. This article originally appeared in the
April, 1982 Multi-Tasker. It is still the only available specification of
the ODS-1 file system. --- The Editor^IS204^G
.PAGE
Files-11 On-Disk Structure Specification
.SKIP 2
19-June-1975
.SKIP
Revised 15-June-1977
.SKIP
Revised 15-April-1981
.SKIP
Edited 20-September-1986
.SKIP 3
Copyright (c) 1975, 1977, 1981
.BREAK
Digital Equipment Corporation, Maynard, Mass.
.SKIP 2
The material included in this functional specification, including but not
limited to instruction times and operating speeds, is for informational
purposes only. All such material is subject to change without notice.
Consequently, Digital Equipment Corporation makes no claim and shall not be
liable for its accuracy.
.SKIP 2
This software is furnished under a license for use only on a single computer
system and may be copied only with the inclusion of the above copyright notice.
This software, or any other copies thereof, may not be provided or otherwise
made available to any other person except for use on such system and to one
who agrees to these license terms. Title to and ownership of the software
shall at all times remain in Digital Equipment Corporation.
.SKIP 2
The information in this document is subject to change without notice and should
not be construed as a commitment by Digital Equipment Corporation.
.SKIP 2
Digital Equipment Corporation assumes no responsibility for the use or
reliability of its software on equipment which is not supplied by Digital
Equipment Corporation.
.PAGE
.HL 1 Scope
This document is a specification of the on-media structure that is
used by Files-11. Files-11 is a general purpose file structure which is
intended to be the standard file structure for all medium to large PDP-11
systems. Small systems such as RT-11 are specifically excluded
because the complexity of Files-11 imposes too great a burden on their
simplicity and small size.
This document describes structure level 1 of Files-11, also referred
to as ODS-1 (on-disk structure version 1). This is implemented on
the RSX-11 family, (RSX-11M, RSX-11M-Plus, IAS and RSX-11D) and on VMS.
This document describes the final level of functionality for ODS-1.
Structure level 2 (ODS-2) is implemented on VMS and is the basis for
all new disk structure enhancements.
.HL 2 Summary of Revisions Made to This Specification
.LIST
.LE
Expanded file characteristics to include most ODS-2 options.
.LE
Corrected H.FPRO to H.DFPR.
.LE
Added new fields to home block for date and count of home block
modifications.
.LE
Added single directory support description and home block field.
.LE
Added field in home block for pack serial number (H.PKSR).
.LE
Added description of modified storage control block format to support
large disks.
.LE
Restricted maximum number of blocks supported on a volume to 1,044,480.
.LE
Restricted ODS-1 to one block "clusters".
.LE
Restricted ODS-1 to single volume structures.
.LE
Clarified and expanded references to operating system support and relationship
to ODS-2.
.LE
Removed RMS-11 definitions, to be provided in separate specification common
to ODS-1 and ODS-2.
.END LIST
.HL 1 Medium
Files-11 is a structure which is imposed on a medium. That medium
must have certain properties, which are described in the following section.
Generally speaking, block addressable storage devices such as disks and
DECtape are suitable for Files-11; hence, Files-11 structured media are
generically referred to as disks.
.HL 2 Volume
The basic medium that carries a Files-11 structure is referred to
as a volume. A volume (also often referred to as a unit) is defined as an
ordered set of logical blocks. A logical block is an array of 512 8-bit
bytes. The logical blocks in a volume are consecutively numbered from 0
to (n-1), where the volume contains n logical blocks.
The number assigned to
a logical block is called its logical block number, or LBN. Files-11 is
theoretically capable of describing volumes up to 2**32 blocks in size.
In practice, a volume should be at least 100 blocks in size to be useful.
Current implementations of Files-11 handle volumes up to 2**24 blocks.
The logical blocks of a volume must be randomly addressable. The
volume must also allow transfers of any length up to 65K bytes; consecutively
numbered logical blocks are transferred until the byte count is satisfied.
In other words, the volume can be viewed as a partitioned array of bytes.
It must allow reads and writes of arrays of any length less than 65K bytes,
provided that they start on a logical block boundary and that the length
is a multiple of four bytes. When only part of a block is written, the
contents of the remainder of that logical block are undefined.
.HL 2 Volume Sets
This section is of historical interest only. ODS-1 does not and
will not support volume sets. A volume set is a collection of
related units that are normally treated as one logical device in the usual
operating system concept. Each unit contains its own Files-11 structure;
however, files on the various units in a volume set may be referenced with
a relative volume number, which uniquely determines which unit in the set the
file is located on. Other sections in this specification make
occasional reference to volume sets and relative volume number where "hooks"
for their implementation exist. Since volume sets have not been implemented
as yet, however, no complete specification is provided here.
.HL 1 Files
Any data in a volume or volume set that are of any interest (i.e.,
all blocks not available for allocation) are contained in a file. A file is
an ordered set of virtual blocks, where a virtual block is an array of 512
8-bit bytes. The virtual blocks of a file are consecutively numbered from
1 to n, where n blocks have been allocated to the file.
The number assigned
to a virtual block is called (obviously) its virtual block number, or VBN.
Each virtual block is mapped to a unique logical block in the volume set
by Files-11. Virtual blocks may be processed in the the same manner as
logical blocks. Any array of bytes less than 65K in length may be read or
written, provided that the transfer starts on a virtual block boundary and
that its length is a multiple of four bytes.
.HL 2 File ID
Each file in a volume set is uniquely identified by a File ID. A
File ID is a binary value consisting of 48 bits (3 PDP-11 words). It is
supplied by the file system when the file is created, and must be supplied
by the user whenever he wishes to reference a particular file.
The three words of the File ID are used as follows:
.SKIP
Word 1##File Number
.SKIP
.LM +8
Locates the file within a particular unit of the volume set. File numbers
must lie in the range 1 through 65,535. The set of file numbers on a unit
is moderately (but not totally) dense; at any instant in time, a file
number uniquely identifies one file within that unit.
.LM -8
.SKIP
Word 2##File Sequence Number
.SKIP
.LM +8
Identifies the current use of an individual file number on a unit. File
numbers are re-used; when a file is deleted its file number becomes
available for future use for some other file. Each time a file number is
re-used, a different file sequence number is assigned to distinguish the
uses of that file number. The file sequence number is essential since is
is perfectly legal for users to remember and attempt to use a File ID
long after that file has been deleted.
.LM -8
.SKIP
Word 3##Relative Volume Number
.SKIP
.LM +8
Identifies which unit of a volume set the file is located on. Volume sets
are, at present, not implemented; the only legal value for the relative volume
number in any context is zero.
.LM -8
.HL 2 File Header
Each file on a Files-11 volume is described by a file header. The
file header is a block that contains all the information necessary to
access the file. It is not part of the file; rather, it is contained in
the volume's index file. (The index file is described in section 5.1).
The header block is organized into four areas, of which the first three
are variable in size.
.HL 3 Header Area
The information in the header area permits the file system to verify
that this block is in fact a file header and, in particular, is the header
being sought by the user. It contains the file number and file sequence
number of the file, as well as its ownership and protection codes. This
area also contains offsets to the other areas of the file header, thus
defining their size. Finally, the header area contains a user attribute
area, which may be used by the user to store a limited amount of data
describing the file.
.HL 3 Ident Area
The ident area of a file header contains identification and accounting data
about the file. Stored here are the primary name of the file; its creation
date and time; revision count, date and time; and expiration date.
.HL 3 Map Area
The map area describes the mapping of virtual blocks of the file to the logical
blocks of the volume. The mapping data consists of a list of retrieval
pointers. Each retrieval pointer describes on logically contiguous segment of
the file. The map area also contains the linkage to the next extension segment
of the file, if such exists.
.HL 3 End Checksum
The last two bytes of the file header contain a 16-bit additive checksum of the
preceding 255 words of the file header. The checksum is used to help verify
that the block is in fact a file header.
.HL 2 Extension Headers
Since the file header is of fixed size, it is inevitable that for some
files the mapping information does not fit in the allocated space. A file with
a large amount of mapping data is therefore represented with a chain of file
headers. Each header maps a consecutive set of virtual blocks; the extension
linkage in the map area links the headers together in order of ascending
virtual block numbers.
Multiple headers are also needed for files that span units in a volume
set. A header may only map logical blocks located on its unit; therefore, a
multi-volume file is represented by headers on all units that contain portions
of that file.
.HL 2 File Header - Detailed Description
This section describes in detail the items contained in the file
header. Each item is identified by a symbol which represents the offset
address of that item within its area in the file header. Any item may be
located in the file header by locating the area to which it belongs, and then
adding the value of its offset address. Users who concern themselves with
the contents of file headers are strongly urged to use the offset symbols.
The symbols may be defined in assembly language programs by calling and
invoking the macro FHDOF$, which may be found in the macro library of any
system that supports Files-11. Alternatively, one may find the macro in
the file F11MAC.MAC.
.HL 3 Header Area Description
The header area of the file header always starts of byte 0. It
contains the basic information needed for checking the validity of accesses
to the file.
.HL 4 H.IDOF##1 byte##Ident Area Offset
.LM +9
.SKIP
This byte contains the number of 16-bit words between the start of the file
header and the start of the ident area. It defines the location of the ident
area and the size of the header area.
.LM -9
.HL 4 H.MPOF##1 byte##Map Area Offset
.LM +9
.SKIP
This byte contains the number of 16-bit words between the start of the file
header and the start of the map area. It defines the location of the map
area and, together with H.IDOF, the size of the ident area.
.LM -9
.HL 4 H.FNUM##2 bytes##File Number
.LM +9
.SKIP
This word contains the file number of the file.
.LM -9
.HL 4 H.FSEQ##2 bytes##File Sequence Number
.LM +9
.SKIP
This word contains the file sequence number of the file.
.LM -9
.HL 4 H.FLEV##2 bytes##File Structure Level
.LM +9
.SKIP
The file structure level is used to identify different versions of Files-11
as they affect the structure of the file header. This permits upward
compatibility of file structures as Files-11 evolves, in that the structure
level word identifies the version of Files-11 that created this particular
file. This document describes version 1 of Files-11; the only legal contents
for H.FLEV is 401 octal.
.LM -9
.HL 4 H.FOWN##2 bytes##File Owner UIC
.LM +9
H.PROG = H.FOWN + 0##Programmer (Member) Number
.BREAK
H.PROJ = H.FOWN + 1##Project (Group) Number
.SKIP
This word contains the binary User Identification Code (UIC) of the owner of
the file. The file owner is usually (but not necessarily) the creator of the
file.
.LM -9
.HL 4 H.FPRO##2 bytes##File Protection Code
.LM +9
.SKIP
This word controls what access all users in the system may have to the file.
Accessors of a file are categorized according to the relationship between
the UIC of the accessor and the UIC of the owner of the file. Each category
is controlled by a four bit field in the protection word. The category of
the accessor is selected as follows:
.SKIP
System##Bits 0 - 3
.LM +8
.SKIP
The accessor is subject to system protection if the project number of the
UIC under which he is running is 10 octal or less.
.LM -8
.SKIP
Owner###Bits 4 -7
.LM +8
.SKIP
The accessor is subject to owner protection if the UIC under which he is
running exactly matches the file owner UIC.
.LM -8
.SKIP
Group###Bits 8 - 11
.LM +8
.SKIP
The accessor is subject to group protection if the project number of his
UIC matches the project number of the file owner UIC.
.LM -8
.SKIP
World###Bits 12 - 15
.LM +8
.SKIP
The accessor is subject to world protection if he does not fit into any of
the above categories.
.LM -8
.SKIP
Four types of access intents are defined in Files-11: Read, Write, Extend
and Delete. Each four bit field in the protection word is bit encoded to
permit or deny any combination of the four types of access to that category
of accessors. Setting a bit denies that type of access to that category.
The bits are defined as follows (these values apply to a right-justified
protection field):
.SKIP
FP.RDV##Deny read access
.BREAK
FP.WRV##Deny write access
.BREAK
FP.EXT##Deny extend access
.BREAK
FP.DEL##Deny delete access
.SKIP
When a user attempts to access a file, protection checks are performed in all
the categories to which he is eligible, in the order: System, Owner, Group,
World. The user is granted access to the file if any of the categories to
which he is eligible grants his access.
.LM -9
.HL 4 H.FCHA##2 bytes##File Characteristics
.LM +9
H.UCHA = H.FCHA + 0##User Controlled Characteristics
.BREAK
H.SCHA = H.FCHA + 1##System Controller Characteristics
.SKIP
The user controlled characteristics byte contains the following flag bits:
.SKIP
.LM +8
.INDENT -8
Reserved, 1 bit
.SKIP
.INDENT -8
UC.NID##Set if incremental dump (backup) is to be disabled for this file.
.SKIP
.INDENT -8
UC.WBC##Set if the file is to be write-back cached; i.e., if a cache is used
for the file data, data written by a user is only written back to the disk when
it is removed from the cache. Clear for write-through cache operation.
.SKIP
.INDENT -8
UC.RCK##Set if the file is to be read-checked. All read operations on the file,
including reads of the file header(s), are performed with a read,
read-compare to assure data integrity.
.SKIP
.INDENT -8
UC.WCK##Set if the file is to be write-checked. All write operations on the
file, including modifications of the file header(s), are performed with
a write, read-compare to assure data integrity.
.SKIP
.INDENT -8
UC.CNB##Set if the file is allocated contiguous best effort; i.e., as
contiguous as possible.
.SKIP
.INDENT -8
UC.DLK##Set if the file is deaccess-locked. This bit is used as a flag warning
that the file was not properly closed and may contain inconsistent data. Access
to the file is denied if this bit is set.
.SKIP
.INDENT -8
UC.CON##Set if the file is logically contiguous; i.e., if for all virtual
blocks in the file, virtual block i maps to logical block k+i for some constant
k. This bit may be implicitly set or cleared by file system operations that
allocate space to the file; the user may only clear it explicitly.
.LM -8
.SKIP
The system controlled characteristics byte contains the following
flag bits:
.SKIP
.LM +8
.INDENT -8
Reserved, 3 bits
.SKIP
.INDENT -8
Reserved, Access Control List
.SKIP
.INDENT -8
SC.SPL##Set if the file is an intermediate file for spooling.
.SKIP
.INDENT -8
SC.DIR##Set if the file is a directory.
.SKIP
.INDENT -8
SC.BAD##Set if there is a bad data block in the file. This bit is as yet
unimplemented. It is intended for dynamic bad block handling.
.SKIP
.INDENT -8
SC.MDL##Set if the file is marked for delete. If this bit is set, further
accesses to the file are denied, and the file is physically deleted
when no users are accessing it.
.LM -8
.LM -8
.HL 4 H.UFAT##32 bytes##User Attribute Area
.LM +9
.SKIP
This area is intended for the storage of a limited quantity of "user file
attributes", i.e., any data the user deems useful for processing the file
that is not part of the file itself. An example of the use of the user
attribute area is presented in section 6.1 (FCS File Attributes).
.LM -9
.HL 4 S.HDHD##46 bytes##Size of Header Area
.LM +10
.SKIP
This symbol represents the total size of the header area containing all of
the above entries.
.LM -10
.HL 3 Ident Area Description
The ident area of the file header begins at the word indicated by
H.IDOF. It contains identification and accounting data about the file.
.HL 4 I.FNAM##6 bytes##File Name
.LM +9
.SKIP
These three words contain the name of the file, packed three Radix-50
characters to the word. This name usually, but not necessarily, corresponds
to the name of the file's primary directory entry.
.LM -9
.HL 4 I.FTYP##2 bytes##File Type
.LM +9
.SKIP
This word contains the type of the file in the form of three Radix-50
characters.
.LM -9
.HL 4 I.FVER##2 bytes##Version Number
.LM +9
.SKIP
This word contains the version number of the file in binary form.
.LM -9
.HL 4 I.RVNO##2 bytes##Revision Number
.LM +9
.SKIP
This word contains the revision count of the file. The revision count is
the number of times the file has been accessed for write.
.LM -9
.HL 4 I.RVDT##7 bytes##Revision Date
.LM +9
.SKIP
The revision date is the date on which the file was last deaccessed after being
accessed for write. It is stored in ASCII in the form "DDMMYY", where DD are
two digits representing the day of the month, MMM are three characters
representing the month, and YY are the last two digits of the year.
.LM -9
.HL 4 I.RVTI##6 bytes##Revision Time
.LM +9
.SKIP
The revision time is the time of day on which the file was last deaccessed
for write. It is stored in ASCII in the format "HHMMSS", where HH are the
hour, MM are the minute, and SS are the second.
.LM -9
.HL 4 I.CRDT##7 bytes##Creation Date
.LM +9
.SKIP
These seven bytes contain the date on which the file was created. The format
is the same as that of the revision date above.
.LM -9
.HL 4 I.CRTI##6 bytes##Creation Time
.LM +9
.SKIP
These six bytes contain the time of day at which the file was created. The
format is the same as that of the revision time above.
.LM -9
.HL 4 I.EXDT##7 bytes##Expiration Date
.LM +9
.SKIP
These seven bytes contain the date on which the file becomes eligible to be
deleted. The format is the same as that of the revision and creation dates
above.
.LM -9
.HL 4 ########1 byte##Unused
.LM +10
.SKIP
This unused byte is present to round up the size of the ident area to a word
boundary.
.LM -10
.HL 4 S.IDHD##46 bytes##Size of Ident Area
.LM +10
.SKIP
This symbol represents the size of the ident area containing all of the
above entries.
.LM -10
.HL 3 Map Area Description
The map area of the file header begins at the word indicated by
H.MPOF. It contains the information necessary to map the virtual blocks of
the file to the logical blocks of the volume.
.HL 4 M.ESQN##1 byte##Extension Segment Number
.LM +9
.SKIP
This byte contains the value n, where this header is the (n+1)th header of the
file; i.e., headers of a file are numbered sequentially starting with 0.
.LM -9
.HL 4 M.ERVN##1 byte##Extension Relative Volume Number
.LM +9
.SKIP
This byte contains the relative volume number of the unit in the volume set
that contains the next sequential extension header for this file. If there
is no extension header, or if the extension header is located on the same
unit as this header, this byte contains 0.
.LM -9
.HL 4 M.EFNU##2 bytes##Extension File Number
.LM +9
.SKIP
This word contains the file number of the next sequential extension header
for this file. If there is no extension header, this word contains 0.
.LM -9
.HL 4 M.EFSQ##2 bytes##Extension File Sequence Number
.LM +9
.SKIP
This word contains the file sequence number of the next sequential
extension header for this file. If there is no extension header, this
word contains 0.
.LM -9
.HL 4 M.CTSZ##1 byte##Block Count Field Size
.LM +9
.SKIP
This byte contains a count of the number of bytes used to represent the count
field in the retrieval pointers in the map area. The retrieval pointer format
is described in section 3.4.3.9 below.
.LM -9
.HL 4 M.LBSZ##1 byte##LBN Field Size
.LM +9
.SKIP
This byte contains a count of the number of bytes used to represent the
logical block number field in the retrieval pointers in the map area.
The contents of M.CTSZ and M.LBSZ must add up to an even number.
.LM -9
.HL 4 M.USE###1 byte##Map Words in Use
.LM +9
.SKIP
This byte contains a count of the number of words in the map area that are
presently occupied by retrieval pointers.
.LM -9
.HL 4 M.MAX###1 byte##Map Words Available
.LM +9
.SKIP
This byte contains the total number of words available for retrieval pointers
in the map area.
.LM -9
.HL 4 M.RTRV##variable##Retrieval Pointers
.LM +9
.SKIP
This area contains the retrieval pointers that actually map the virtual blocks
of the file to the logical blocks of the volume. Each retrieval pointer
describes a consecutively numbered group of logical blocks which is part of
the file. The count field contains the binary value n to represent a
group of (n+1) logical blocks. The logical block number field contains the
logical block number of the first logical block in the group.
.SKIP
Thus, each
retrieval pointer maps virtual blocks j through (j+n) into logical blocks
k through (k+n), respectively, where j is the total number plus one of
virtual blocks represented by all preceding retrieval points in this and
all preceding headers of the file, n is the value contained in the count
field, and k is the value contained in the logical block number field.
.SKIP
Although the data in the map area provideds for arbitrarily extensible
retrieval pointer forms, Files-11 has defined only three. Of these, only
the first is currently implemented. The other two are presented out of
historical interest; they will never be supported.
.LM +11
.SKIP 2
.INDENT -11
Format 1: M.CTSZ = 1
.BREAK
M.LBSZ = 3
.SKIP
The total retrieval pointer length is four bytes. Byte 1 contains the
high order bits of the 24-bit LBN. Byte 2 contains the count field, and
bytes 3 and 4 contain the low 16 bits of the LBN.
.TEST PAGE 6
.SKIP
.NO FILL
.NO JUSTIFY
+----------+----------+
| Count | High |
+----------+- -+
| Low order LBN |
+----------+----------+
.JUSTIFY
.FILL
.SKIP 2
.INDENT -11
Format 2: M.CTSZ = 2
.BREAK
M.LBSZ = 2
.SKIP
The total retrieval pointer length is four bytes. The first word contains
a 16-bit count field and the second word contains a 16-bit LBN field.
.TEST PAGE 6
.SKIP
.NO FILL
.NO JUSTIFY
+----------+----------+
| Count |
+----------+----------+
| Low order LBN |
+----------+----------+
.JUSTIFY
.FILL
.SKIP 2
.INDENT -11
Format 3: M.CTSZ = 2
.BREAK
M.LBSZ = 4
.SKIP
The total retrieval pointer length is six bytes. The first word contains
a 16-bit count field and the second and third words contain a 32-bit LBN field.
.TEST PAGE 8
.SKIP
.NO FILL
.NO JUSTIFY
+----------+----------+
| Count |
+----------+----------+
| Low order LBN |
+- -+- -+
| High order LBN |
+----------+----------+
.JUSTIFY
.FILL
.LM -11
.LM -8
.HL 4 S.MPHD##10 bytes##Size of Map Area
.LM +10
.SKIP
This symbol represents the size of the map area, not including the space used
for the retrieval pointers.
.LM -10
.HL 3 End Checksum Description
The header check sum occupies the last two bytes of the file header.
It is verified every time a header is read, and is recomputed every time a
header is written.
.HL 4 H.CKSM##2 bytes##Block Checksum
.LM +8
.SKIP
This word is a simple additive checksum of all other words in the block. It
is computed by the following PDP-11 routine or its equivalent:
.SKIP
.NO FILL
.NO JUSTIFY
MOV Header-address, R0
CLR R1
MOV _#255., R2
10$: ADD (R0)+, R1
SOB R2, 10$
MOV R1, (R0)
.JUSTIFY
.FILL
.LM -8
.HL 3 File Header Layout
.TEST PAGE 26
.SKIP
Header Area
.SKIP
.NO FILL
.NO JUSTIFY
+-------------------+-------------------+
H.MPOF | Map Area Offset | Ident Area Offset | H.IDOF
+-------------------+-------------------+
| File Number | H.FNUM
+-------------------+-------------------+
| File Sequence Number | H.FSEQ
+-------------------+-------------------+
| File Structure Level | H.FLEV
+-------------------+-------------------+ H.FOWN
H.PROJ | File Owner UIC | H.PROG
+-------------------+-------------------+
| File Protection | H.FPRO
+-------------------+-------------------+ H.FCHA
H.SCHA | System Char's | User Char's | H.UCHA
+-------------------+-------------------+
| | H.UFAT
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
/ User File Attribute Area /
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+ S.HDHD
.JUSTIFY
.FILL
.SKIP 2
.TEST PAGE 50
Ident Area
.SKIP
.NO FILL
.NO JUSTIFY
+-------------------+-------------------+
| | I.FNAM
+- -+- -+
| File Name |
+- -+- -+
| |
+-------------------+-------------------+
| File Type | I.FTYP
+-------------------+-------------------+
| Version Number | I.FVER
+-------------------+-------------------+
| Revision Number | I.RVNO
+-------------------+-------------------+
| | I.RVDT
+- -+- -+
| Revision Date |
+- -+- -+
| |
+-------------------+- -+
I.RVTI | | |
+- +-------------------+
| |
+- -+- -+
| Revision Time |
+- -+- -+
+-------------------+- -+
I.CRDT | | |
+- +-------------------+
| |
+- -+- -+
| Creation Date |
+- -+- -+
| |
+-------------------+-------------------+
| | I.CRTI
+- -+- -+
| Creation Time |
+- -+- -+
| |
+-------------------+-------------------+
| | I.EXDT
+- -+- -+
| Revision Date |
+- -+- -+
| |
+-------------------+- -+
| Unused | |
+-------------------+-------------------+ S.IDHD
.JUSTIFY
.FILL
.SKIP 2
.TEST PAGE 23
Map Area
.SKIP
.NO FILL
.NO JUSTIFY
+-------------------+-------------------+
M.ERVN | Extension RVN | Extension Seq Num | M.ESQN
+-------------------+-------------------+
| Extension File Number | M.EFNU
+-------------------+-------------------+
| Extension File Sequence Number | M.EFSQ
+-------------------+-------------------+
M.LBSZ | LBN Field Size | Count Field Size | M.CTSZ
+-------------------+-------------------+
M.MAX | Map Words Avail. | Map Words in Use | M.USE
+-------------------+-------------------+ S.MPHD
| | M.RTRV
+- -+- -+
| |
/ Retrieval Pointers /
| |
+- -+- -+
| |
+-------------------+-------------------+
| File Header Checksum | H.CKSM
+-------------------+-------------------+
.JUSTIFY
.FILL
.HL 1 Directories
Files-11 provides directories to allow the organization of files in a
meaningful way. While the File ID is sufficient to locate a file uniquely on
a volume set, it is hardly mnemonic. Directories are files whose sole function
is to associate file name strings with File IDs.
.HL 2 Directory Hierarchies
Since directories are files with no special attributes, directories
may list files that are in turn directories. Thus, the user may construct
directory hierarchies of arbitrary depth and complexity to structure his files
as he pleases.
.HL 3 User File Directories
Current implementations of Files-11 all support a two level directory
hierarchy which is tied in with the user identification mechanism of the
operating system. Each UIC is associated with a user file directory (UFD).
References to files that do not specify a directory are generally defaulted
to the user's UIC. All UFDs are listed in the volume's MFD under a file name
constructed from the UIC. A UIC of [n,m] associates with a directory name of
"nnnmmm.DIR;1" where nnn and mmm are n and m padded out to three digits
each with leading zeroes. Note that all number conversions are done in octal.
Two points should be noted here. The UFD structure described here is
not intrinsically part of the Files-11 on-disk structure; rather, it is a
convenient cataloging system applied by various operating systems. Also, there
is no hard and fast relationship between the owner UIC of a file and the UFD
in which it is listed. Generally, they do correspond, but not necessarily.
.HL 2 Directory Structure
A directory is a file consisting of 16-byte records. It is structured
as an FCS fixed length record file, with no carriage control attributes (see
section 6 for a description of FCS files). Each record is a directory entry.
The entries are not required to be ordered, or densely packed, nor do they
have any other relationship to each other, except that no two entries in one
directory may contain the same name, type, and version. Each entry contains
the following:
.SKIP
.LM +9
.INDENT -9
File ID##The three word binary File ID of the file that this directory entry
represents. If the file number portion of the File ID field is zero, then
this record is empty and may be used for a new directory entry.
.SKIP
.INDENT -9
Name#####The name of the file may be up to 9 characters. It is stored as three
words, each containing three Radix-50 packed characters.
.SKIP
.INDENT -9
Type#####The type of the file (also historically referred to as the extension)
may be up to three characters. It is stored as one word of Radix-50 packed
characters.
.SKIP
.INDENT -9
Version##The version number of the file is stored in binary in one word.
.LM -9
.HL 3 Directory File Entry Layout
.SKIP
.NO FILL
.NO JUSTIFY
.TEST PAGE 16
+-------------------+-------------------+
| |
+- -+- -+
| File ID |
+- -+- -+
| |
+-------------------+-------------------+
| |
+- -+- -+
| Name |
+- -+- -+
| |
+-------------------+-------------------+
| Type |
+-------------------+-------------------+
| Version |
+-------------------+-------------------+
.JUSTIFY
.FILL
.HL 2 Directory Protection
Since directories are files with no special characteristics, they may
be accessed like all other files, and are subject to the same protection
mechanism. However, implementations of Files-11 support three special functions
for the management of directories, namely FIND, REMOVE and ENTER. A user
performing such a directory operation must first have the following privileges
to be allowed the various functions:
.SKIp
.LM +8
FIND:####Read
.BREAK
REMOVE:##Read, Write
.BREAK
ENTER:###Read, Write
.LM -8
.SKIP
Note that the same privilege is required for both ENTER and REMOVE. The
recovery for an operation that involves a REMOVE at the beginning of the
sequence is an ENTER.
.HL 1 Known Files
Clearly, any file system must maintain some data structure on the
medium which is used to control the file organization. In Files-11 this
data is kept in five files. These files are created when a new volume is
initialized. They are unique in that their File IDs are known constants.
These five files have the following uses:
File ID 1,1,0 is the index file. The index file is the root of the
entire Files-11 structure. It contains the volume's bootstrap block and the
home block, which is used to identify the volume and locate the rest of the
file structure. The index file also contains all of the file headers for
the volume, and a bitmap to control the allocation of file headers.
File ID 2,2,0 is the storage bitmap file. It is used to control
the allocation of logical blocks on the volume.
File ID 3,3,0 is the bad block file. It is a file containing all of
the known bad blocks on the volume.
File ID 4,4,0 is the volume master file directory, or MFD. It
forms the root of the volume's directory structure. The MFD lists the five
known files, all first level user directories, and whatever other files the
user chooses to enter.
File ID 5,5,0 is the system core image file. Its use is operating
system dependent; its basic purpose is to provide a file of known File ID
for the use of the operating system.
.HL 2 Index File
The index file is File ID 1,1,0. It is listed in the MFD as
INDEXF.SYS;1. The index file is the root of the Files-11 structure in that
it provides the means for identification and initial access to a Files-11
volume, and contains the access data for all files on the volume, including
itself.
.HL 3 Bootstrap Block
Virtual block 1 of the index file is the volume's boot block. It is
always mapped to logical block 0 of the volume. If the volume is the system
device of an operating system, the boot block contains an operating system
dependent program which reads the operating system into memory when the boot
block is read and executed by a machine's hardware bootstrap. If the volume
is not a system device, the boot block contains a small program that
outputs a message on the system console to inform the operator to that effect.
.HL 3 Home Block
Virtual block 2 of the index file is the volume's home block. The
logical block containing the home block is the first good block on the volume
from the sequence 1, 256, 512, 768, 1024, 1280 ... (256*n). The purpose of the
home block is to identify the volume as Files-11, establish the specific
identity of the volume, and serve as the ground zero entry point into the
volume's file structure. The home block is recognized as a home block by the
presence of checksums in known places and by the presence of predictable
values in certain locations.
Items contained in the home block are identified by symbolic offsets
in the same manner as items in the file header. The symbols may be defined
in assembly language programs by calling and invoking the macro HMBOF$,
which may be found in the macro library of any system that supports Files-11.
Alternatively, one may find the macro in the file F11MAC.MAC.
.HL 4 H.IBSZ##2 bytes##Index File Bitmap Size
.LM +9
.SKIP
This 16-bit word contains the number of blocks that make up the index file
bitmap. (The index file bitmap is discussed in section 5.1.4.) This
value must be non-zero for a valid home block.
.LM -9
.HL 4 H.IBLB##4 bytes##Index File Bitmap LBN
.LM +9
.SKIP
This doubleword contains the starting logical block address of the index
file bitmap. Once the home block of a volume has been found, it is this
value that provides access to the rest of the index file and to the volume.
The LBN is stored with the high order in the first 16 bits, followed by the
low order portion. This value must be non-zero for a valid home block.
.LM -9
.HL 4 H.FMAX##2 bytes##Maximum Number of Files
.LM +9
.SKIP
This word contains the maximum number of files that may be present on the
volume at any time. This value must be non-zero for a valid home block.
.LM -9
.HL 4 H.SBCL##2 bytes##Storage Bitmap Cluster Factor
.LM +9
.SKIP
This word contains the cluster factor used in the storage bitmap file. The
cluster factor is the number of blocks represented by each bit in the storage
bitmap. Volume clustering is not implemented in ODS-1; the only legal value
for this item is 1.
.LM -9
.HL 4 H.DVTY##2 bytes##Disk Device Type
.LM +9
.SKIP
This word is an index identifying the type of disk that contains this volume.
It is currently not used and always contains 0.
.LM -9
.HL 4 H.VLEV##2 bytes##Volume Structure Level
.LM +9
.SKIP
This word identifies the volume's structure level. Like the file structure
level, this word identifies the version of Files-11 which created this volume
and permits upward compatibility of media as Files-11 evolves. The volume
structure level is affected by all portions of the Files-11 structure except
the contents of the file header. This document describes Files-11 version 1;
the only legal values for the structure level are 401 and 402 octal. The
former (401) is the standard value for most volumes. The latter (402) is an
advisory that the volume contains a multiheader index file. (A multiheader
index file is required to support more than about 26,000 files. The index
file may in fact be multiheader without the volume having a structure level
of 402.)
.LM -9
.HL 4 H.VNAM##12 bytes##Volume Name
.SKIP
.LM +9
This area contains the volume label as an ASCII string. It is padded out to
12 bytes with nulls. The volume label is used to identify individual Files-11
volumes.
.LM -9
.HL 4 ########4 bytes##Unused
.HL 4 H.VOWN##2 bytes##Volume Owner UIC
.LM +9
.SKIP
This word contains the binary UIC of the owner of the volume. The format is
the same as that of the file owner UIC stored in the file header.
.LM -9
.SKIP
.HL 4 H.VPRO##2 bytes##Volume Protection Code
.LM +10
.SKIP
This word contains the protection code for the entire volume. Its contents are
coded in the same manner as the file protection code stored in the file header,
and it is interpreted in the same way in conjunction with the volume owner UIC.
All operations on all files on the volume must pass both the volume and the
file protection check to be permitted. (Refer to the discussion on file
protection in section 3.4.1.7).
.LM -10
.HL 4 H.VCHA##2 bytes##Volume Characteristics
.SKIP
.LM +10
This word contains bits which provide additional control over access to the
volume. The following bits are defined:
.SKIP
.LM +8
.INDENT -8
CH.NDC##Obsolete, used by RSX-11D / IAS. Set if device control functions are
not permitted on this volume. Device control functions are those which can
threaten the integrity of the volume, such as direct reading and writing of
logical blocks, etc.
.SKIP
.INDENT -8
CH.NAT##Obsolete, used by RSX-11D / IAS. Set if the volume may not be
attached, i.e., reserved for exclusive use by one task.
.SKIP
.INDENT -8
CH.SDI##Set if the volume contains only a single directory. If this bit is
set, no directories should be created on the volume other than the MFD. The
access methods should also be informed of this situation, e.g. by setting the
DV.SDI bit in the UCB device characteristics word.
.LM -8
.LM -10
.HL 4 H.DFPR##2 bytes##Default File Protection
.LM +10
.SKIP
This word contains the file protection that is assigned to all files
created on this volume if no file protection is specified by the user.
.LM -10
.HL 4 ########6 bytes##Unused
.HL 4 H.WISZ##1 byte##Default Window Size
.SKIP
.LM +10
This word contains the number of retrieval pointers used for the
"window" (in-memory file access data) when files are accessed on the volume,
if not otherwise specified by the accessor.
.LM -10
.HL 4 H.FIEX##1 byte##Default File Extend
.LM +10
.SKIP
This byte contains the number of blocks that are allocated to a file when a
user extends the file and asks for the system default value for allocation.
.LM -10
.HL 4 H.LRUC##1 byte##Directory Pre-Access Limit
.LM +10
.SKIP
This byte contains a count of the number of directories to be stored in the
file system's directory access cache. More generally, it is an estimate of
the number of concurrent users of the volume, and its use may be generalized
in the future.
.LM -10
.HL 4 H.REVD##7 bytes##Date of Last Home Block Revision
.LM +10
.SKIP
This field (ill defined field) is in the standard ASCII date format and
reflects the date of the last modifications to fields in the home block.
.LM -10
.HL 4 H.REVC##2 bytes##Count of Home Block Revisions
.LM +10
.SKIP
This field reflects the number of above mentioned modifications.
.LM -10
.HL 4 ########2 bytes##Unused
.HL 4 H.CHK1##2 bytes##First Checksum
.LM +10
.SKIP
This word is an additive checksum of all entries preceding in the home block
(i.e., all those listed above). It is computed by the same sort of
algorithm as the file header checksum (see section 3.4.4.1).
.LM -10
.SKIP
.HL 4 H.VDAT##14 bytes##Volume Creation Date
.LM +10
.SKIP
This area contains the date and time that the volume was initialized. It is
in the format "DDMMMYYHHMMSS", followed by a single null. (The same format
is used in the ident area of the file header, section 3.4.2).
.LM -10
.HL 4 ########382 bytes##Unused
.LM +10
.SKIP
This area is reservied for the relative volume table for volume sets. This
field is not used, although some versions of DSC referred to this area.
.LM -10
.HL 4 H.PKSR##4 bytes##Pack Serial Number
.LM +10
.SKIP
This area contains the manufacturer supplied serial number for the physical
volume. For last trace devices, the pack serial number is contained on the
volume in the manufacturer data. For other devices the user must supply this
information manually. The serial number is contained in the home block for
convenience and consistency.
.LM -10
.HL 4 ########12 bytes##Unused
.HL 4 H.INDN##12 bytes##Volume Name
.LM +10
.SKIP
This area contains another copy of the ASCII volume label. It is padded out
to 12 bytes with spaces. It is placed here in accordance with the volume
identification standard (STD 167).
.LM -10
.HL 4 H.INDO##12 bytes##Volume Owner
.SKIP
.LM +10
This area contains an ASCII expansion of the volume owner UIC in the form
"[proj,prog]". Both numbers are expressed in decimal and are padded to
three digits with leading zeroes. The area is padded out to 12 bytes with
trailing spaces. It is placed here in accordance with the volume
identification standard (STD 167).
.LM -10
.HL 4 H.INDF##12 bytes##Format Type
.LM +10
.SKIP
This field contains the ASCII string "DECFILE11A" padded out to 12 bytes
with spaces. It identifies the volume as being of Files-11 format.
It is placed here in accordance with the volume
identification standard (STD 167).
.LM -10
.HL 4 ########2 bytes##Unused
.HL 4 H.CHK2##2 bytes##Second Checksum
.LM +10
.SKIP
This word is the last word of the home block. It contains an additive
checksum of the preceding 255 words of the home block, computed according
to the algorithm in section 3.4.4.1.
.LM -10
.HL 3 Home Block Layout
.SKIP
.NO FILL
.NO JUSTIFY
.TEST PAGE 9
+-------------------+-------------------+
| Index File Bitmap Size | H.IBSZ
+-------------------+-------------------+
| Index File Bitmap LBN | H.IBLB
+- -+- -+
| |
+-------------------+-------------------+
| Maximum Number of Files | H.FMAX
+-------------------+-------------------+
.TEST PAGE 18
| Storage Bitmap Cluster Factor | H.SBCL
+-------------------+-------------------+
| Disk Device Type | H.DVTY
+-------------------+-------------------+
| Volume Structure Level | H.VLEV
+-------------------+-------------------+
| | H.VNAM
+- -+- -+
| |
+- -+- -+
| Volume Name |
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 4
| | Unused
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 4
| Volume Owner UIC | H.VOWN
+-------------------+-------------------+
| Volume Protection | H.VPRO
+-------------------+-------------------+
.TEST PAGE 4
| Volume Characteristics | H.VCHA
+-------------------+-------------------+
| Default File Protection | H.DFPR
+-------------------+-------------------+
.TEST PAGE 6
| | Unused
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 2
H.FIEX | Def. File Extend | Def. Window Size | H.WISZ
+-------------------+-------------------+
.TEST PAGE 8
H.REVD | | Directory Limit | H.LRUC
+- -+-------------------+
| |
+- -+- -+
| Volume Modification Date |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 2
| Volume Modification Count | H.REVC
+-------------------+-------------------+
.TEST PAGE 2
| | Unused
+-------------------+-------------------+
.TEST PAGE 2
| First Checksum | H.CHK1
+-------------------+-------------------+
.TEST PAGE 14
| | H.VDAT
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| Volume Creation Date |
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 8
| | Unused
+- -+- -+
| |
/ -+- /
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 4
| Pack Serial Number | H.PKSR
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 12
| | Unused
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 12
| | H.INDN
+- -+- -+
| |
+- -+- -+
| Volume Name |
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 12
| | H.INDO
+- -+- -+
| |
+- -+- -+
| Volume Owner |
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 12
| | H.INDF
+- -+- -+
| |
+- -+- -+
| Format Type |
+- -+- -+
| |
+- -+- -+
| |
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 4
| | Unused
+-------------------+-------------------+
| Second Checksum | H.CHK2
+-------------------+-------------------+
.JUSTIFY
.FILL
.HL 3 Index File Bitmap
The index file bitmap is used to control the allocation of file
numbers (and hence file headers). It is simply a bit string of length n,
where n is the maximum number of files permitted on the volume (contained
in offset H.FMAX in the home block). The bitmap spans as many blocks as
are necessary to hold it, i.e., maximum number of files divided by 4096 and
rounded up. The number of blocks in the bitmap is contained in offset H.IBSZ
of the home block.
The bits in the index file bitmap are numbered sequentially from 0
to (n-1) in the obvious manner, i.e., from right to left in each byte, and in
order of increasing byte address. Bit j is used to represent file number
(j+1): If the bit is 1, then that file is in use; if the bit is 0, then that
file number is not in use and may be assigned to a newly created file.
The index file bitmap starts at virtual block 3 of the index file and
continues through VBN (2+m), where m is the number of blocks in the bitmap.
It is located at the logical block indicated by offset H.IBLB in the home block.
.HL 3 File Headers
The rest of the index file contains all the file headers for the volume.
The first 16 file headers (for file numbers 1 through 16) are logically
contiguous with the index file bitmap to facilitate their location; the rest
may be allocated wherever the file system sees fit. Thus, the first 16 file
headers may be located from the data in the home block (H.IBSZ and H.IBLB) while
the rest must be located through the mapping data in the index file header. The
file header for file number n is located at virtual block (2+m+n), where m is
the number of blocks in the index file bitmap.
.HL 2 Storage Bitmap File
The storage bitmap file is File ID 2,2,0. It is listed in the MFD as
BITMAP.SYS;1. The storage bitmap is used to control the available space on a
unit. It consists of a storage control block which contains summary information
about the unit, and the bitmap itself which lists the availability of
individual blocks.
.HL 3 Storage Control Block
Virtual block 1 of the storage bitmap is the storage control block.
It contains summary information intended to optimize allocation of space on the
unit. The storage control block has the following format for disks with less
than 516,096 (4096*126) blocks:
.SKIP
.NO FILL
.NO JUSTIFY
3 bytes:##Unused (zero)
1 byte:###Number of storage bitmap blocks (less than 127)
2 bytes:##Number of free blocks in bitmap block 1
2 bytes:##Free block pointer in bitmap block 1
2 bytes:##Number of free blocks in block 2
2 bytes:##Free block pointer in bitmap block 2
##########.
##########.
##########.
2 bytes:##Number of free blocks in block n
2 bytes:##Free block pointer in bitmap block n
4 bytes:##Size of the unit in logical blocks
.JUSTIFY
.FILL
.SKIP
The storage control block has the following format for disks with more
than 516,096 (4096*126) blocks:
.SKIP
.NO FILL
.NO JUSTIFY
3 bytes:####Unused (zero)
1 byte:#####Number of storage bitmap blocks (greater than 126)
4 bytes:####Size of the unit in logical blocks
246 bytes:##Unused (zero)
.JUSTIFY
.FILL
.SKIP
Note: Current implementations of Files-11 do not correctly initialize the
word pairs containing the number of free blocks and the free block pointer
for each bitmap block, nor are those values maintained as space is allocated
and freed on the unit. They are therefore best looked upon as (2*n) garbage
words, and should not be used by future implementations of Files-11 until
the disk structure is formally updated.
.HL 3 Storage Bitmap
Virtual blocks 2 through (n+1) are the storage bitmap itself. It is
best viewed as a bit string of length m, numbered from 0 to (m-1), where m
is the total number of logical blocks on the unit rounded up to the next
integer multiple of 4096. The bits are addressed in the usual manner (packed
right to left in sequentially numbered bytes). Since each virtual block
holds 4096 bits, n blocks (where n = m/4096) are used to hold the bitmap.
Bit j of the bitmap represents logical block j of the volume; if the
bit is set, the block is free; if clear, the block is allocated. Clearly,
the last k bits of the map are always clear, where k is the difference between
the true size of the volume and m, the length of the bitmap.
The size of the bitmap is limited to 256 blocks. In fact, due to
existing implementations on all RSX system, the retrieval pointers must be
in one of the following two forms:
.SKIP
.LIST
.LE
A single retrieval pointer mapping the entire BITMAP.SYS file.
.LE
Two retrieval pointers, the first mapping only the storage bitmap control block,
and the second mapping the entire storage bitmap.
.END LIST
This restriction limits ODS-1 to a volume of 4096*255 blocks (1,044,480 blocks)
or about 500 megabytes.
.HL 2 Bad Block File
The bad block file is File ID 3,3,0. It is listed in the MFD as
BADBLK.SYS;1. The bad block file is simply a file containing all of the known
bad blocks on the volume.
.HL 3 Bad Block Descriptor
Virtual block 1 of the bad block file is the bad block descriptor for
the volume. It is always located on the last good block of the volume. This
block may contain a listing of the bad blocks on the volume, produced by a
bad block scan program or diagnostic. The format of the bad block data is
identical to the map area of a file header, except that the first four
entries (M.ESQN, M.ERVN, M.EFNU and M.EFSQ) are not present. The last word
of the block contains the usual additive checksum. (See section 3.4.3 for a
description of the map area.) This block is included in the bad block file
to save the data it contains for future re-initializations of the volume.
.HL 3 Bad Block Descriptor Layout
.SKIP
.NO FILL
.NO JUSTIFY
.TEST PAGE 15
+-------------------+-------------------+
| LBN Field Size | Count Field Size |
+-------------------+-------------------+
| Map Words Avail. | Map Words in Use |
+-------------------+-------------------+
| |
+- -+- -+
| |
/ Retrieval Pointers /
| |
+- -+- -+
| |
+-------------------+-------------------+
| Block Checksum |
+-------------------+-------------------+
.JUSTIFY
.FILL
.HL 2 Master File Directory
The master file directory (MFD) is File ID 4,4,0. It is listed in the
MFD (itself) as 000000.DIR;1. The MFD is the root of the volume's directory
structure. It lists the five known files, plus whatever the user chooses to
enter. In the two level UFD structure described in section 4.1.1, the MFD
contains entries for all user file directories.
.HL 2 Core Image File
The core image file is File ID 5,5,0. It is listed in the MFD as
CORIMG.SYS;1. Its use is operating system dependent. In general, it provides
a file of known File ID for the use of the operating system for use as a swap
area, as a monitor overlay area, etc.
.HL 1 FCS File Structure
File Control Services (FCS) is a user level interface to Files-11. Its
principal features are a record control facility that allows sequential processing
of variable length records, and sequential and random access to fixed length
record files. FCS interfaces to the virtual block facility provided by the
basic Files-11 structure.
.HL 2 FCS File Attributes
FCS stores attribute information about the file in the file header's
user attribute area (H.UFAT - see section 3.4.1.9). It uses only the first
7 words; the rest are ignored by FCS, but are reserved by DEC. RMS uses an
additional 3 words - 10 words in all - for relative and indexed file
attributes.
The following items are contained in the attribute area; they are
identified by the usual symbolic offsets relative to the start of the attribute
area. The offsets may be defined in assembly language programs by calling
and invoking the macro FDOFF$. Flag values and bits may be defined by calling
and invoking the macro FCSBT$. These macros are in the system macro library
of any operating system that supports Files-11. Alternatively, all these values
are defined in the system object library of any system that supports Files-11,
and may be obtained at link time.
.HL 3 F.RTYP##1 byte##Record Type
.LM +7
.SKIP
This byte identifies the type of records contained in this file. The
following three values are legal:
.SKIP
R.FIX##Fixed length records
.BREAK
R.VAR##Variable length records
.BREAK
R.SEQ##Sequenced variable length records
.LM -7
.HL 3 F.RATT##1 byte##Record Attributes
.LM +7
.SKIP
This byte contains record attribute bits that control the handling of records
under various contexts. The following flag bits are defined:
.LM +8
.SKIP
.INDENT -8
FD.FTN##Use Fortran carriage control. The first byte of each record is to be
interpreted as a standard Fortran carriage control character when the record
is copied to a carriage control device.
.SKIP
.INDENT -8
FD.CR###Use implied carriage control. When the file is copied to a carriage
control device, each record is to be preceded by a line feed and followed by
a carriage return. FD.FTN and FD.CR are mutually exclusive.
.SKIP
.INDENT -8
FD.PRN##The two byte sequence number field for R.SEQ record format is to be
interpreted as print control information. See section 6.3.3.1 for format of
print information.
.SKIP
.INDENT -8
FD.BLK##Records do not cross block boundaries if set. Generally, there is dead
space at the end of each block; how this is handled is explained in the
description of record formats in section 6.3.
.LM -8
.LM -7
.HL 3 F.RSIZ##2 bytes##Record Size
.LM +7
.SKIP
In a fixed length record file, this word contains the size of the records in
bytes. In a variable length record file, this word contains the size in bytes
of the longest record in the file.
.LM -7
.HL 3 F.HIBK##4 bytes##Highest VBN Allocated
.LM +7
.SKIP
This 32-bit number is a count of the number of virtual blocks allocated to the
file. Since this value is maintained by FCS, it is usually correct; however,
it is not guaranteed, since FCS is a user level package.
.LM -7
.HL 3 F.EFBK##4 bytes##End of File Block
.LM +7
.SKIP
This 32-bit number is the VBN is which the end of file is located. Both F.HIBK
and F.EFBK are stored with the high order half in the first two bytes, followed
by the low order half.
.LM -7
.HL 3 F.FFBY##2 bytes##First Free Byte
.LM +7
.SKIP
This word is a count of the number of bytes in use in the virtual block
containing the end of file, i.e., it is the offset to the first byte of the
file available for appending. Note that an end of file that falls on a block
boundary may be represented in either of two ways:
.SKIP
1. F.EFBK contains precisely n blocks, F.EFBK contains 512.
.BREAK
2. F.EFBK contains (n+1), F.EFBK contains 0.
.LM -7
.HL 3 S.FATT##14 bytes##Size of Attribute Block
.LM +7
.SKIP
This symbol represents the total number of bytes in the FCS file attribute
block.
.LM -7
.HL 2 FCS File Attribute Block Layout
.SKIP
.NO FILL
.NO JUSTIFY
.TEST PAGE 5
+-------------------+-------------------+
F.RATT | Record Attributes | Record Type | F.RTYP
+-------------------+-------------------+
| Record Size | F.RSIZ
+-------------------+-------------------+
.TEST PAGE 4
| Highest VBN Allocated | F.HIBK
+- -+- -+
| |
+-------------------+-------------------+
.TEST PAGE 6
| End of File VBN | F.EFBK
+- -+- -+
| |
+-------------------+-------------------+
| First Free Byte | F.FFBY
+-------------------+-------------------+ S.FATT
.JUSTIFY
.FILL
.HL 2 Record Structure
This section describes how records are packed in the virtual blocks
of a disk file. In general, FCS treats a disk file as a sequentially numbered
array of bytes. Records are numbered consecutively starting with 1.
.HL 3 Fixed Length Records
In a file containing fixed length records, the records are simply
packed end to end with no additional control information. If the record
length is odd, each record is padded with a single byte. The content of the
pad byte is undefined. For direct access, the address of a record is computed
as follows:
.SKIP
.LM +6
.INDENT -6
Let###n = record number
.BREAK
k = record size in bytes
.BREAK
m = byte address of record in file
.BREAK
q = number of records per block
.BREAK
j = VBN containing the start of the record
.BREAK
i = byte offset within VBN j
.SKIP
.INDENT -6
Then##h = ((k + 1) / 2) * 2 (rounded-up record length)
.BREAK
m = (n - 1) * h
.BREAK
j = (m / 512) + 1 (truncated)
.BREAK
i = m mod 512
.LM -6
The previous discussion assumes that records cross block boundaries,
that is, FD.BLK is not set. If records do not cross block boundaries, they
are limited to 512 bytes, and the following equations apply (variables
defined as above):
.SKIP
.LM +6
h = ((k + 1) / 2) * 2 (rounded-up record length)
.BREAK
q = 512 / k (truncated)
.BREAK
j = ((n - 1) / q) + 1 (truncated)
.BREAK
i = ((n - 1) mod q) * h
.LM -6
.HL 3 Variable Length Records
In a file containing variable length records, records may be up to
32,767 bytes in length. Each record is preceded by a two byte binary count
of the bytes in the record. The count does not include itself. A null record
is represented by a single 0 word. The byte count is always word-aligned; i.e.,
if a record ends on an odd byte boundary, it is padded with a single byte. The
contents of the pad are undefined.
If records do not cross block boundaries (FD.BLK is set), they are
limited to a size of 510 bytes. A byte count of -1 is used as a flag to signal
that there are no more records in a particular block. The remainder of that
block is then dead space, and the next record in the file starts at the
beginning of the next block.
.HL 3 Sequenced Variable Length Records
The format of the sequenced file is identical to a variable length
record file, except that a two-byte sequence number field is located immediately
after the byte count field of each record. This field contains a binary value
which is usually interpreted as the line number of that record (see section
6.1.2, FD.PRN, and section 6.3.3.1).
The sequence number is not returned as part of the data when a record
is read, but is available separately. Note that the record byte count field
counts the sequence number field as well as the data of the record.
.HL 4 Format of 2-Byte Print Control Field in R.SEQ Records
If the FD.PRN bit is set in the record attribute, then the two-byte
"sequence number" field is used to contain carriage control data for the
record. Byte 0 is print control information to act upon before the record
data is output to a unit record device. Byte 1 is print control information
to act upon after the record data is output to a unit record device.
The format of each byte is as follows:
.SKIP
.NO FILL
.NO JUSTIFY
Bit 7 Bits 6 - 0 Meaning
0 0 No carriage control
0 1 - 127 Count of new lines (CR/LF)
Bit 7 Bit 6 Bit 5 Bits 4-0 Meaning
1 0 0 ASCII C0 set Char to output
1 0 1 ASCII C1 set Char to output
1 1 0 Code 0 - 63 Device specific code
1 1 1 - Reserved
.JUSTIFY
.FILL
Note: The print control field is not currently supported by FCS or
RMS-11.