.NONUMBER .LM 0 ^PY^- .PAGE SIZE 58,85 .LM 10 .RM 75 .NO FILL .NO JUSTIFY # .SKIP 5 .CENTER The RSX Multi-Tasker .CENTER May, 1987 .SKIP .CENTER ###^IS144^G"Semper Drunk"^IS204^G .SKIP .CENTER Fine Realtime Commentary Since 1975 .SKIP 6 .CENTER ^&Table of Contents\& .SKIP 2 .TAB STOPS 65 Food for Thought RSX-1 The Editor's Corner RSX-1 Cheap Wine RSX-2 Submitting Articles to the Multi-Tasker RSX-3 And That's The Way Things Are RSX-4 Creative RSX Executive Patching RSX-4 F77 Compiler Bug RSX-8 Letter to the Editor RSX-9 Missing TKB Global Symbol "ERRDEF" RSX-20 Recovery of BRU Multi-Volume Tape Sets RSX-11 Response to December "Bag of Tricks" RSX-15 RSX SIG Leadership Chart RSX-15 ODS-2 Files-11 On-Disk Structure RSX-17 .JUSTIFY .FILL .SKIP 12 .LM +5 .RM -5 Opinions expressed in the editorial section of the Multi-Tasker are those of the Editor. They do not represent the official position of the RSX SIG or that of DECUS leadership in general. .LM -7 .RM +7 .PAGE .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Food for Thought .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT # .SKIP 7 .AUTOPARAGRAPH .CENTER ^&Food for Thought\& .SKIP "The fears of man are many. He fears the shadow of death and the closed doors of the future. He is afraid for his friends and for his sons and of the specter of tomorrow. All his life's journey he walks in the lonely corridors of his controlled fears, if he is a man. For only fools will strut, and only cowards dare cringe." .SKIP 2 .INDENT 30 ^IS144^G- James Warner Bellah^IS204^G .INDENT 30 ^IS144^G##Spanish Man's Grave^IS204^G .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT The Editor's Corner .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .SKIP 9 .CENTER ^&The Editor's Corner\& .SKIP .CENTER Bruce R. Mitchell .SKIP This issue is hitting the streets just about the time that the Spring Symposium is ending. As we go to press, I'm sure there will be many interesting, exciting and significant things happening at Nashville. Recantation of those things would be timely in this issue. Unfortunately, it's late March now, and I seem to have misplaced my crystal ball. The earliest articles from the Spring Symposium will be in the July issue. We have a wunnerful, wunnerful selection of articles this month. The European contingent weighs in strong with two articles. Way to go, guys! Keep up the good work. For those readers intrigued with last month's mention of the ODS-2 ACP, we're publishing a support article for reference when the ACP is released. The ^&ODS-2 Files-11 On-Disk Structure\&, less the file-specific sections, rounds out this month's issue. Send more articles; there are still about 30 of the prints of the Fall 1986 SIG button artwork to give away. These prints are a limited edition, all signed by the artist and certified. The only way you can get one is to contribute an article. And, as always, if you don't want to ^&write\& an article, at least drop a line telling what kind of articles you'd like to ^&see\& in the Multi-Tasker. Turn the Editor's crank, get an editorial. The Editor's crank was turned quite well this month. So were a few others. .SKIP 2 .CENTER ----- Cheap Wine ----- .SKIP 2 .LM +11 .RM -11 "The ^&Multi-Tasker\& Editor has eaten sour grapes, and the users' teeth are set on edge." .LM -11 .RM +11 .SKIP I am so angry I could just spit tacks. Something stinks within DECUS. And generally, when something stinks, it's a sign that the odoriferous something is decaying; sometimes, decaying from within. By the time you read this issue, the elections for the Board of Directors will be accomplished. Therefore, I can continue with the editorial started last month without fear of "electioneering" accusations. There probably will be ^&other\& accusations leveled at me after this hits, but let the chips fall where they may. We're not proud. I stated in last month's issue that ^&The Multi-Tasker\& had to remain neutral on the election. I don't know if this is official graven policy; this is what I was told. But why should an official SIG organ not support candidates who are favorable to the aims of that SIG? I also implied that an unnamed entity may have tried to - hmm, how shall I put this - "influence" the election. That entity is LDEC, the Leadership Development and Election Committee. It is charged with running fair elections, among other things. The flyer accompanying the ballot just crossed my desk several days ago. I am still having somewhat of a difficult time seeing straight. There appears to have been another attempt to influence the vote. I mean the references to candidates as "Slated by the Leadership Development and Elections Committee" or "Slated by petition". This is very bad just by itself, but apparently it wasn't sufficient to put it out on the front page in bold print; it was also tagged to the bottom of each candidate's statement. If this isn't electioneering by making certain candidates appear "blessed and approved", I'll eat my 11/60. I have done some investigation into this. I have chatted with some of the candidates "slated by petition". Their qualifications appear very good to outstanding. But in one particularly grating case, a candidate who received a national leadership award from LDEC was told, when interviewed by LDEC, those qualifications weren't good enough to run for Board. It is surely only a coincidence that some candidates forced to petition appear to wish to change the direction of the Society. It doesn't matter whether that viewpoint is "right" or "wrong"; DECUS is a democratic organization. In such an organization it cannot be wrong to seek to return control to the members. But it sure looks to me as though someone thinks it is. Something stinks within DECUS. I hope it's not too late to cut out the rot. .TEST PAGE 5 .SKIP 2 .CENTER ----- Submitting Articles to the Multi-Tasker ----- Please submit machine readable media if you can. RX01, RX02, RX50, or 9 channel magtape at 800 or 1600 BPI are best. Any RSX volume format is acceptable except ROLLIN or PRESRV. ANSI, BRU and DOS FLX formats are well-liked by the Editor's tape drive. The Editor can now Kermit articles out of other hosts into the Multi-Tasker host. The reverse is unfortunately not true; the Multi-Tasker host is normally an isolate. If you want to submit an article via Kermit, call beforehand with (1) phone number, (2) login for the host machine and (3) system uptimes. 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 page size 58,80; 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 (507)#775-6268 .JUSTIFY .FILL .TEST PAGE 5 .SKIP 2 .CENTER ----- And That's The Way Things Are ----- _... this month in Pool Lowbegone, where the PDP-11 is still going strong, the new doc sets are good-looking, and the tendency of the newsletter editor to flame is above average. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Creative RSX Executive Patching .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Creative RSX Executive Patching\& .SKIP .CENTER James A. McGlinchey .CENTER Software Engineering Consultant .CENTER Post Office Box 81 .CENTER Essex Junction, VT 05452-0081 .CENTER (802) 879-6014 .SKIP RSX has been carefully coded so that many of its SYSgen parameters end up being constants, and all those constants are collected and put into the Exec's SYSCM module. SYSCM contains such items as: .SKIP .LM +5 .NO FILL .NO JUSTIFY $TKPS The line frequency, typically 60 $SYSNM The system's name (DECNET Node Name) $COMEF The global event flags (EFNs 33.-64.) $CKLDC KW11-P clock countdown $SYUIC The system UIC (typically [1,54]) $FMASK Table of system features, shown as bits $DYPMN Days-per-month table $BTMSK Table of bit masks $PKMAX Maximum number of pre-allocated I/O packets $PRIHL POOL monitor task control parameters $PFRSZ " " " " $POLBP " " " " .LM -5 .JUSTIFY .FILL A lot of RSX tweaking and tuning can be done by changing various constants in the Exec and its data areas. Admittedly, many of these items can be changed via MCR or DCL commands, but some can be changed only with a new SYSgen. I hate doing SYSgens. I'd rather apply a patch to RSX to change something that would ordinarily require a SYSGEN. For this reason, I use pregenerated RSX distribution kits for normal RSX systems (if there be such a thing), and often must change something in the Exec. I prefer to make changes to the Executive after all the bootstrap dust has settled. I apply patches with a program run from STARTUP.CMD rather than ZAPping the Executive. Other wizards might argue that ZAP is better for such things, but I find ZAPping the Exec to be troublesome for several reasons: .SKIP .LM +3 .INDENT -3 -##Mistakes made with ZAP can be tragic, as the change is permanent. .SKIP .INDENT -3 -##Changes made via ZAP are not documented, and therefore are not guaranteed to be reproducible. .SKIP .INDENT -3 -##I can't remember how to run ZAP. I have to learn it every time I use it. So I try not to use it. .LM -3 My preferred technique is a patcher program, a listing of which is shown below. The program switches to kernel state via the SWSTK$ macro, applies the changes, and then exits. I prefer this because it is reproducible and easily ported from system to system. The example shown below applies a six character patch to change the system name. The code inserted between the SWSTK$ line and the RETURN line actually does the patching, and this is the only code the user would change to apply other patches. The rest is boilerplate code to switch into kernel state and then exit cleanly after the patch is applied. .SKIP 2 .NO FILL .NO JUSTIFY .TITLE PATCHER - Apply RSX Exec Patches .IDENT /01.00/ .MCALL SWSTK$,EXIT$S PATCH:: SWSTK$ 10$ ; Install dynamic system patches ; All registers are available at this point. MOV _#"GL, $SYSNM ;; Change the System Name MOV _#"IN, $SYSNM+2 ;; to "GLINCH" MOV _#"CH, $SYSNM+4 ; The patch is now installed. Return to user state. RETURN ;; Return to user state 10$: EXIT$S ; and split. .END PATCH .JUSTIFY .FILL .SKIP The following command lines assemble and Task Build the patcher program: .SKIP 2 MAC PATCHER,PATCHER/-SP=LB:[11,10]RSXMC.MAC,SY:''PATCHER .BREAK TKB PATCHER/PR/-CP,PATCHER=PATCHER,LB:[1,54]RSX11M.STB/SS .SKIP Once the basic PATCHER program is created, it can be used for all sorts of things in the RSX Exec. Examples are included below. Some are serious, some frivolous. The examples are just those lines to be inserted into the PATCHER program. .NOTE <<< WARNING WARNING WARNING WARNING WARNING WARNING >>> The examples shown below could cause a system to crash or otherwise malfunction. DO NOT try them just to "see what happens". The examples are for illustration purposes only. .END NOTE .SKIP 2 To change the system clock frequency to 50 Hz.: .SKIP .INDENT 5 MOVB _#50.$TKPS .SKIP 2 To permanently set Event Flag 32.: .SKIP .INDENT 5 BIS _#1,$COMEF .SKIP 2 To cause the Exec to forget that UMRs (Unibus Mapping Registers) are present: .SKIP .INDENT 5 BIC _#HF.UBM,$FMASK .SKIP Several possibilities for creative hacking come to mind as well, such as changing the system clock to 23 Hz, or changing the system name every five seconds, using a rotating table of names. (Fun, but it doesn't show up on RMD). A more extended use of the PATCHER program is a tweak I have been applying to RSX systems ever since I discovered that the preallocated I/O Packet list isn't really preallocated. I/O packets, up to the limit specified via a SYSGEN question, are left allocated upon their first use. Once an I/O packet is allocated by a device driver it is entered in the list of permanently allocated packets. Two problems are encountered with this feature: .SKIP .LM +3 .INDENT -3 -##The preallocated maximum may be too low; if a SET /MAXPKT command responds with two identical numbers, the system could probably use a few more preallocated packets. .SK .INDENT -3 -##The packets are not really preallocated, but are allocated when needed and then left in a list. While this is a nice run time optimization for RSX, it tends to leave preallocated packets scattered all over primary POOL, leaving POOL more fragmented than it could otherwise be. .LM -3 My solution to these problems is the following program. It first changes the maximum number of packets to be left preallocated, and then forces their allocation. It then deallocates them, leaving the maximum number entered in the preallocated I/O packet list. Since the allocation/deallocation is done in a loop running in Executive state, the packets are most likely allocated immediately adjacent to each other, and are located in a bunch at the bottom of POOL. .SKIP 2 .NO FILL .NO JUSTIFY .TITLE FIXPKT - Allocate Preallocated Packets .IDENT /01.00/ .MCALL SWSTK$,EXIT$S,CRASH ; This program allocates all the possible Pre-Allocated ; RSX I/O Packets, leaving them in a contiguous bunch ; at the bottom of POOL. ; ; It optionally enables the user to adjust the maximum ; number of packets to be left in the preallocated list. ; ; Command lines for creation: ; ; MAC FIXPKT,FIXPKT/-SP=LB:[11,10]RSXMC.MAC,SY:''FIXPKT ; TKB FIXPKT/PR/-CP,FIXPKT=FIXPKT,LB:[1,54]RSX11M.STB/SS ; ; Comments begun with double semicolons (;;) indicate code ; which executes in kernel mode. ; START:: MOV _#PKTS,R5 ; Point at packet list SWSTK$ GOTTEM ; enter system state MOVB _#16.,$PKMAX ;; Change Maximum. ;; MOVB $PKMAX,R4 ;; How many are there? 10$: CALL $ALPKT ;; allocate one. BCC 20$ ;; continue if ok. CRASH ;; else crash system. 20$: MOV R0,(R5)+ ;; stash packet address SOB R4,10$ ;; see if more to do. MOVB $PKMAX,R4 ;; now de-allocate packets. 30$: MOV -(R5),R0 ;; going backward thru list CALL $DEPKT ;; and de-allocate 'em SOB R4,30$ ;; all of 'em RETURN ;; back to user state. GOTTEM: EXIT$S ; all done. ; Packet address list PKTS: .BLKW 256. .END START .JUSTIFY .FILL .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT F77 Compiler Bug .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&F77 Compiler Bug\& .SKIP .CENTER Nora K. Narum .CENTER Philip Morris, USA .CENTER PO Box 26603 .CENTER JRC 41-1 .CENTER Richmond, VA###23261 .SKIP We discovered an interesting problem in the Fortran-77 compiler when we patched it up to RSX 3.0 Update C level. If you have two successive single quotes within a quoted string in a PARAMETER statement, for example - .SKIP 2 .NO JUSTIFY .NO FILL Program QUOTE Integer X,Y Character*19 FMT1 Parameter ( FMT1 = '(1X,I2.2,''::'',I2.2)' ) X = 12 Y = 35 Write (UNIT = 5,FMT = FMT1) X, Y End .JUSTIFY .FILL .SKIP 2 the quote processing is incorrect. The above program should print "12::35". Instead, it prints "12:35". Apparently, when the compiler recognizes the second quote, it gobbles both the quote character and the character following it. This can lead to compile errors later, if you're lucky, or just to unexpected results at run time. We have SPRed this problem, and Digital is working on it. In the meantime, we're working around it, and trying not to make changes which will have to be changed back when the compiler is fixed. Most of our uses of the quotes inside quotes come from FORMAT statements inside PARAMETER statements. For those, we're falling back to Hollerith constants to replace the quoted strings. Using this technique, the program above becomes: .SKIP 2 .NO JUSTIFY .NO FILL Program QUOTE Integer X,Y Character*19 FMT1 Parameter ( FMT1 = '(1X,I2.2,2H::,I2.2)' ) X = 12 Y = 35 Write (UNIT = 5,FMT = FMT1) X, Y End .JUSTIFY .FILL .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Letter to the Editor .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Letter to the Editor\& .SKIP .CENTER James Bostwick .CENTER Cargill, Incorporated .CENTER PO Box 9300 .CENTER Minneapolis, MN 55440 .SKIP I am very concerned by the handling of the recent DECUS Board of Directors election. The treatment of candidates in the flyer which accompanied the election ballot was no less than appalling. Specifically, the flyer shows favoritism toward the LDEC approved candidates, while carefully implying that the petitioners are somewhat less than equal. This may be in strict keeping with the bylaws, but it is no way to run a fair election. There ^&are\& certain areas of the globe where one only votes for "approved" candidates, but I refuse to believe that DECUS is among them. It should also be noted that DECUS specifically prohibits any form of "campaigning" in its official publications. If nothing else, LDEC is guilty of violating this policy in its presentation of the slate of candidates as "approved" or "not approved". If I had sent a pre-election letter to this newsletter stating that I heartily approved of thus-and-so for DECUS board, it would have been in violation of policy and would not have been published. The least LDEC can do is abide by its own policies. If, in fact, such cavalier treatment of candidates is within the bylaws of DECUS, those bylaws should be changed immediately. Once a candidate has gained a place on the ballot, any distinction between LDEC "approval" and placement by petition should be eliminated. The implication that petitioners are somehow less worthy than "approved" nominees is grossly unfair, not to mention misleading. The amazing thing about the "dual slate" of candidates in this case is the lack of distinction in qualifications between the "LDEC approved" nominees and those who had to force their names on the ballot. Perusal of the nominees' statements shows the three petitioners to be quite as qualified for consideration as Board members as the other nominees. Why were such eminently qualified individuals not selected as candidates? It is disturbing to note that two of the petitioners openly state concerns with the direction of the "New DECUS". Furthermore, with one exception, the "approved" candidates are all intimately connected with the "New DECUS". Could it be that the petitioners are unacceptable for purely political reasons? Could it be, in fact, that LDEC selects candidates as much for their acceptability to LDEC itself as for their qualifications to sit on the Board of Directors of DECUS? Could it be that LDEC is less than objective in carrying out its role of recruting and nominating candidates for the Board? I certainly hope not. However, the evidence of the election pamphlet raises serious doubts. Let me state emphatically that I have no problem with ANY of the candidates on the ballot. All appear qualified for the position to which they aspire. My problem is specifically with LDEC and the way in which the candidates were presented to DECUS membership. At a minimum, those sections of the bylaws pertaining to conduct of elections, and the policies which guide LDEC in carrying out election duties require immediate and thorough review. The least that the "New DECUS" can do for its membership is conduct fair and unbiased elections. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Missing TKB Global Symbol "ERRDEF" .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Missing TKB Global Symbol "ERRDEF"\& .SKIP .CENTER Nora K. Narum .CENTER Philip Morris, USA .CENTER PO Box 26603 .CENTER JRC 41-1 .CENTER Richmond, VA###23261 .SKIP In the November, 1986 issue of The Software Dispatch, DEC documents a problem with the high-level language interface to the Executive directives in which tasks build with an undefined reference to ERRDEF. This problem originated in Update C, and is (allegedly) fixed in Update D. DEC suggests two ways to work around this problem. The first, and simplest, is to ignore it. We have trouble doing that because the undefined symbol causes TKB to return an exit status other than success, and that upsets our automated application-system builder. The second solution offered by DEC is to include a GBLDEF option in each task's TKB command file so that the ERRDEF symbol is resolved. We don't like that one either, because we have a large base of installed tasks and associated task-build command files, and adding the GBLDEF to each one is a lot of work. What we've done is to include an additional module in SYSLIB.OLB which provides a definition for ERRDEF. We created a very short MACRO program: .SKIP 2 .NO JUSTIFY .NO FILL .TITLE ERRDEF ERRDEF:: .END .JUSTIFY .FILL .SKIP We assemble it, then insert the resulting module into SYSLIB.OLB (LBR LB:[1,1]SYSLIB.OLB=ERRDEF.OBJ/EP/IN). Now our tasks build with their old command files and no unresolved symbols. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Recovery of BRU Multi-Volume Tape Sets .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Recovery of BRU Multi-Volume Tape Sets\& .SKIP .CENTER David Maden .CENTER Computer Section .CENTER Swiss Institute for Nuclear Research .CENTER CH-5234 Villigen .CENTER Switzerland .SKIP 2 1. The Problem Careful reading of the RSX Utilities Manual reveals that the /AP switch with BRU is valid only to append backup sets to the end of a single volume magnetic tape set. Once backup sets extend to more than one tape, the /AP switch is no longer permitted. The manual implies that use of the /AP switch in these circumstances should result in an error message. Unfortunately, certain versions of BRU (V07.24 of RSX-11M V4.2/B, in particular) do not enforce this restriction. The result, for the unwary, can be a multi-volume magnetic tape set containing backup sets which cannot be restored using BRU, since BRU is adamant that a backup set used in a restore operation must start on the first volume of a multi-volume backup set. The purpose of this note is to describe a means of recovering these backup sets. The recovery procedure appears to work satisfactorily for backup sets completely contained on a single volume. The recovery of backup sets which not only start after the first volume but also span more than one volume is not solved completely, although a procedure which appears to achieve partial recovery of such backup sets is described. The recovery procedure requires access to a VAX/VMS system with two magnetic tape drives of density compatible with the RSX generated BRU tape. Tests have been made using an RSX-11M V4.2/B system and a VMS V4.5 system. .SKIP 2 2. The Solution In the interest of clarity, let us consider the case of a 3-volume magnetic tape set. Assume that the contents of the volumes are as follows: .SKIP 2 Tape 1: File 1####/BAC:BB1, part 1 of 2 .SKIP Tape 2: File 1####/BAC:BB1, part 2 of 2 .BREAK #########File 2####/BAC:BB2, complete .BREAK #########File 3####/BAC:BB3, part 1 of 2 .SKIP Tape 3: File 1####/BAC:BB3, part 2 of 2 .SKIP Given this volume set, BRU is able to restore backup set BB1 normally, but attempts to restore backup sets BB2 or BB3 fail. In this section, a procedure is described for recovering BB2 (i.e., a backup set which is completely contained on a single volume). The recovery of backup set BB3 is described in section 3. The recovery procedure for BB2 is to copy the backup set to another tape in such a way that it appears to BRU to be an appended backup set on a single volume tape set. All attempts to perform the required copy using PIP on RSX-11M failed, because, while BRU writes ANSI type labels on magnetic tapes, it does not follow standard ANSI procedure for encoding the record lengths. As a result, the more forgiving VAX/VMS COPY command must be used. The procedure is as follows: .SKIP .LIST .LE On an RSX system, initialize a target magnetic tape using BRU. Assuming that UFD LB:[g,m] is a nonexistent UFD and that MTnn: is a tape drive available on the RSX system, load the tape on the drive and issue the command: .SKIP .INDENT 5 BRU /MOU LB:[g,m] MTnn: .SKIP The following messages will appear: .SKIP .INDENT 5 BRU - Starting Tape 1 on MTnn: .INDENT 5 BRU - End of Tape 1 on MTnn: .INDENT 5 BRU -- * WARNING * No files found .INDENT 5 BRU - Completed Note that the target tape must be initialized using BRU on an RSX system. Use of the INI command under RSX or VMS is inadequate. .LE Log in to the VMS system and allocate two tape drives: .SKIP .INDENT 5 ALL MTAm: .INDENT 5 ALL MTAn: .SKIP Load the tape containing backup set BB2 on MTAm: and load the target tape on MTAn:. .LE Mount the two tapes using the commands: .SKIP .INDENT 5 MOU MTAm: /OVER=(OWNER,ID) .INDENT 5 MOU MTAn: /OVER=(OWNER,ID) /BLOCK=4144 .SKIP Note the specification of the blocksize on the output magnetic tape. .LE Copy BB2 to the target magnetic tape using the command: .SKIP .INDENT 5 COPY MTAm:"BB2" MTAn: /LOG .SKIP Note that the quotation marks are required syntax. .END LIST The resulting target tape can be read by BRU on an RSX system and the backup set, BB2, can be restored to disk in the usual way. .SKIP 2 3. Recovery Procedure for a Split Backup Set If the above recovery procedure is attempted for a backup set such as BB3 which is split between two tape volumes, a VAX operator request to mount the continuation volume of BB3 is obtained at the end of tape 2. Unfortunately, the format of tape 3 is such that it is impossible to satisfy this request, and the recovery procedure fails. No completely successful method of recovering such backup sets has been found, though the following method has achieved partial recovery. It is described here as stimulation for further investigation. The purpose of the procedure is firstly to modify tape 2 so that VMS COPY believes that there is no continuation tape for BB3. The procedure of section 2 is then followed to copy the first part of BB3 to a target tape which has been initialized with BRU. The target tape is then modified so that it again has a format corresponding to a BRU backup set which has been continued on a second volume. The resulting tape, together with tape 3, is used as input to BRU to restore BB3 to a disk. The normal format of an ANSI format tape which continues onto a subsequent tape is, according to the VMS documentation, as follows: .SKIP 2 .INDENT 5 HDR1##HDR2##*##...Data...##*##EOV1##EOV2 .SKIP 2 where * represents a tape mark, and EOV1 and EOV2 are 80-byte records containing the ASCII strings "EOV1" and "EOV2" in the first 4 bytes, respectively. For a tape which does not continue, the format is: .SKIP 2 .INDENT 5 HDR1##HDR2##*##...Data...##*##EOF1##EOF2 .SKIP 2 EOF1 and EOF2 are also 80-byte records with the same structure as EOV labels except for the substitution of "F" for "V" in the third byte. The recovery procedure is therefore as follows: .SKIP .LIST .LE Modify tape 2 so that the EOV1 and EOV2 labels are converted to EOF1 and EOF2 labels. This can be done via a simple Macro program. Our method, however, was to use the SIG tape copy program TPC to copy the tape to a disk file. DMP was then used to locate the EOV labels so that they could be patched into EOF labels by ZAP. A new tape was finally written using TPC. (The new tape must be longer than the original so that TPC does not give trouble with end of tape.) .LE Use the procedure of section 2 to copy the first part of backup set BB3 to a new target tape. .LE Reverse step 1 with the target tape to convert the EOF labels back into EOV labels. .LE Use the resulting tape together with the original tape 3 as input to BRU to restore the backup set. .END LIST Plausible though it seems, this recovery procedure for a split backup set is not perfect. During tests made at SIN during the preparation of this note (no case has yet arisen here where such a recovery is necessary, so no great amount of time has been invested in finding a complete solution), BRU reported lost data records at the start of the second part of the backup set during the restore operation. Some files were missing on the restored disk. Most files however, were found to be present, correct and complete. The reason for these problems presumably results from the simplistic patching of the first tape in the backup set which, in turn, is a result of the fact that the BRU tape format is unpublished (at least for the lesser mortals outside DEC). Despite these limitations, the procedure is published here as incentive to study the problem further should the need be sufficiently pressing. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Response to December Bag of Tricks .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Response to December "Bag of Tricks"\& .SKIP .CENTER W. B. Langdon .CENTER CERL .CENTER Kelvin Avenue .CENTER Leatherhead .CENTER Surrey KT22 7SE .CENTER England .SKIP ^IS144^GThe following is a response to the article in the December 1986 issue "Bag of Tricks" about tracking task build dates. Thanks to the submittor for these comments. #--##The Editor^IS204^G .SKIP The December 1986 issue of ^&The Multi-Tasker\&, with the "Bag of Tricks: MACRO-11" article by Barton Bruce was very interesting. It is important to note that the $$DBTS .PSECT and $DBTS global label must be placed in the task's root segment, if the task is overlaid. Those concerned with the size of the root (all of us?) can place the code which converts the stored date and time to ASCII into a separate module. The resulting module can then be placed in an overlay segment. This approach uses only 40 decimal bytes in the root segment. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT RSX SIG Leadership Chart .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&RSX SIG Leadership Chart\& .SKIP .CENTER Ed Cetron .CENTER SIG Long Range Planning Coordinator .SKIP ^IS144^GThe SIG leadership chart was revamped at the Spring "Woods" meeting in February. This chart would have accompanied the meeting report, but arrived just one day too late to make it in. Shucks!#--##The Editor^IS204^G .PAGE # .PAGE .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Files-11 On-Disk Structure Specification .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Files-11 On-Disk Structure Specification\& .SKIP .CENTER Digital Equipment Corporation .CENTER Maynard, MA .SKIP ^IS144^GThis article is presented to lay the foundation for an article scheduled later this year on an ODS-2 ACP for RSX.#--##The Editor^IS204^G .SKIP 2 Files-11 On-Disk Structure Specification .SKIP 2 15-Jan-1979 .BREAK Edited 30-Mar-1987 .SKIP 2 Copyright (c) 1979 .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 used by Files-11. Files-11 is a general purpose file structure 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 2 of Files-11, also referred to as ODS-2 (on-disk structure 2). It contains feature and reliability improvements over structure level 1 (ODS-1). This version of the specification is subsetted to describe only the features implemented at present (VMS Version 1.5). .HL 2 Conventions All numerical values in this document are in decimal radix, unless indicated otherwise. Within the file structure are fields containing binary integers of various lengths. Unless otherwise indicated, all these fields are in the standard numerical format, which means that the most significant bits are stored in the highest numbered address. In the descriptions of various structures on the disk, there are fields labelled "not used". These fields must be zero, so that they can be made nonzero for future use. Since they are reserved for future use, programs reading these structures should not assume that these fields are in fact zero. .HL 1 Medium Files-11 is a structure 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. The logical blocks of a volume must be randomly addressable. The volume must also allow transfers of any length up to 65K bytes, in multiples of four bytes. When a transfer is longer than 512 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. The logical blocks of a volume are grouped into clusters. The cluster is the basic unit of space allocation on the volume. Each cluster contains one or more logical blocks; the number of blocks in a cluster is known as the volume cluster factor, or storage map cluster factor. A volume is identified as a Files-11 volume by the home block. The home block is located at a defined physical location on the volume, and is identified by the presence of checksums and predictable values. The home block contains a volume label, which is a string of up to 12 ASCII characters. The characters are restricted to the printing ASCII set (i.e., excluding control characters and RUBOUT). Further, it is recommended that volume labels be restricted to alphanumerics only to avoid conflicts with the command languages of supporting systems. The volume label of a volume may not be null. .HL 2 Volume Sets A volume set is a collection of related volumes 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 volumes in a volume set may be referenced with a relative volume number, which uniquely determines which volume in the set the file is located on. A volume set has an associated structure name, which is a string of up to 12 ASCII characters identifying the volume set. The character set limitations of the volume label also apply to the structure name. The structure name may not be null. .HL 3 Tightly Coupled Volume Set A tightly coupled volume set is a volume set which is consistent and self-identifying. The volume labels of the volumes making up the set must be unique within the set, and must be different from the structure name. Relative volume one of the set contains a file which lists the volume labels of all the volumes in the set, thus associating volume labels with relative volume numbers. Each volume is identified as being part of the set by carrying the structure name, its volume label, and its relative volume number. .HL 3 Loosely Coupled Volume Set A loosely coupled volume set is a collection of volumes which is not self-identifying. There is no file listing the volume labels. Only one file may cross from any one volume in the set to another, and files in the set which cross volumes may be processed only sequentially. Correct sequencing of the volumes that hold a particular file is the responsibility of the system operator. There are checks that catch most handling errors, but they cannot be foolproof. The purpose of the loosely coupled volume set is to emulate multi-volume magtape, and allow a file to be read or written sequentially with only one volume mounted at a time. .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 is the highest numbered block allocated to the file. The number assigned to a virtual block is called its virtual block number, or VBN. Virtual blocks are mapped to unique logical blocks in the volume set by Files-11. Virtual blocks may be processed in 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. For most files, all VBNs less than or equal to the highest VBN allocated map to some LBN in the volume set. Such files are said to be dense. Files which are sparse contain virtual blocks which are not allocated logical blocks. .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 volume of the volume set. File numbers ordinarily 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 volume. .LM -8 .SKIP Word 2##File Sequence Number .SKIP .LM +8 Identifies the current use of an individual file number on a volume. File numbers are reused; when a file is deleted, its file number becomes available for future use for some other file. Each time a file number is reused, 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 after that file is deleted. .LM -8 .SKIP Word 3##Relative Volume Number .SKIP .LM +8 Identifies which volume of a volume set the file is located on. If the volume in question is not a member of a volume set, this word is zero. If the volume is part of a volume set, then the relative volume number, or RVN, lies in the range from 1 to 65,535. In any context where a particular volume of a volume set can be identified as the "current volume", such as a file extension linkage, a relative volume number of zero means the current volume. When a file is referred to in the context of the volume on which it resides, it should be referred to with a relative volume number of zero, regardless of the RVN assigned to that volume. .LM -8 .SKIP File Number Extension .SKIP .LM +8 If the maximum number of files permitted on the volume (as recorded in the home block) is greater than 65,535, then the high byte of the relative volume number becomes a high order extension to the file number. The volume set size is then limited to 255 volumes, while the range of allowable file numbers extends from 1 to (2**24)-1. When 24-bit file numbers are used, the file system should not create files whose file number is an integer multiple of 65,536; i.e., whose low 16 bits are zero. Such file numbers break existing PDP-11 software such as FCS-11. .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 containing all information necessary to access the file. It is not part of the file; rather, it is contained in the volume's index file. The header block is organized into six areas, of which the first five 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 is the particular header 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. .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; 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 logical blocks of the volume. The mapping data consists of a list of retrieval pointers. Each retrieval pointer describes one group of consecutively numbered logical blocks allocated to the file. Retrieval pointers are arranged in the order of the virtual blocks they represent. .HL 3 Access Control List The access control list is an optional area that contains a list of users allowed access to the file. The access control list makes it possible to describe user communities for a particular file that cannot be expressed with the regular protection classes. .HL 3 Reserved Area This optional area is reserved for used by CSS or special applications. It is not used by standard Files-11 systems. .HL 3 End Checksum The last two bytes of the file header contain a 16-bit additive checksum of the preceding 255 header words. The checksum is used to help verify that the block is in fact a file header. .HL 2 Multi-Header Files 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 header area links the headers together in order of ascending virtual block numbers. The extension pointer in each file header is the File ID of the next header in sequence. .HL 2 Multi-Volume Files Multiple headers are also needed for files spanning units in a volume set. A header may only map logical blocks located on its volume; therefore, a multi-volume file is represented by headers on all volumes containing portions of that file. In a multi-volume file on a loosely coupled volume set, the File ID of the first header on each continuation volume always has the value 7,7,n, where n is the RVN of the volume on which the file starts plus the number of preceding volumes containing portions of the 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 PDP-11 (and VAX compatibility mode) assembly language programs by calling and invoking the macro FHDL2$, which may be found in the macro library of any system that supports Files-11. Alternatively, one may find the macro in the file OD2MAC.MAC. VAX native mode assembly language programs can define a corresponding set of file header offsets by invoking the macros $FH2DEF, $FI2DEF and $FM2DEF. These macros are located in the macro library LIB.MLB. Source for these macros is located in the file F11DEF.MAR. .HL 3 Validity A valid file header is defined by the following rules: .LIST .LE The contents of H.IDOF is no less that the offset H.FOWN/2. .LE The four offset bytes are related in the manner: (H.IDOF) .LE. (H.MPOF) .LE. (H.ACOF) .LE. (H.RSOF). .LE The high byte of H.FLEV contains the value 2. .LE The low byte of H.FLEV contains a value greater than or equal to 1. .LE The word H.FNUM contains the file number. .LE The word H.FSEQ contains the file sequence number. .LE The high byte of H.FRVN contains the extended part of the file number, if any. .LE The contents of the byte H.USE must be less than or equal to (H.ACOF) - (H.MPOF). .END LIST A deleted file header conforms to the format of a valid file header with the following exceptions: .LIST .LE SC.MDL is set in H.FCHA. .LE H.FNUM and H.FCHA contain zero. .LE The file header checksum contains zero. .END LIST .HL 3 Header Area Description The header area of the file header always starts at 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.ACOF##1 byte##Access Control List 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 access control list. It defines the location of the ACL and, together with H.MPOF, the size of the map area. .LM -9 .HL 4 H.RSOF##1 byte##Reserved 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 reserved area. The reserved area is not used by Files-11 itself, and may be used by CSS or special applications. Together with H.ACOF, this byte defines the size of the access control list. The size of the reserved area is implied by the contents of H.RSOF and the end of the header block. .LM -9 .SKIP The presence of the ident, map, ACL and reserved areas are optional. Absence of any area is signalled not by a zero offset, but by equality of the two offsets that define the area's size. All five areas are variable in length; implementations of Files-11 must check the length of a particular area before attempting to reference a particular entry. .HL 4 H.FSEG##2 bytes##Extension Segment Number .LM +9 .SKIP This word 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 H.FLEV##2 bytes##Structure Level and Version .LM +9 .SKIP The file structure level and version are 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. .SKIP This document describes structure level 2 of Files-11. The high byte of H.FLEV must contain the value 2. The low byte contains the version number, which must be greater than or equal to 1. The version number is incremented whenever compatible additions are made to the Files-11 structure that may be safely ignored by an old version of the file system. This document describes version 1 of structure level 2. .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.FRVN##2 bytes##Relative Volume Number .LM +9 .SKIP This word holds part of the third word of the File ID when appropriate. This is usually referred to as the relative volume number. When used as such (i.e., to indicate the volume of a volume set), it is not recorded in the file header, since the RVN of a volume may change during a file's life, and the RVN portion of a File ID may be zero or nonzero, depending on the context. .SKIP However, when the high byte of the RVN is used as an extension to the file number, it is recorded in the high byte of this word. The low byte of H.FRVN is always zero. .LM -9 .HL 4 H.EFNU##2 bytes##Extension File Number .LM +10 .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 zero. .LM -10 .HL 4 H.EFSQ##2 bytes##Extension File Sequence Number .LM +10 .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 zero. .LM -10 .HL 4 H.ERVN##2 bytes##Extension Relative Volume Number .LM +10 .SKIP This word contains the relative volume number of the volume 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 volume as this header, this word contains zero. .LM -10 .HL 4 H.UFAT##32 bytes##User Attribute Area .LM +10 .SKIP This area is used by the record manager, or any other higher level access mechanism, to store information necessary for processing the file (e.g., record control data, EOF mark, etc.). .LM -10 .HL 4 H.FCHA##4 bytes##File Characteristics .LM +10 H.UCHA = H.FCHA + 0##User Controlled Characteristics .BREAK H.SCHA = H.FCHA + 1##System Controlled Characteristics .SKIP The user controlled characteristics byte contains the following flag bits: .SKIP .LM +8 .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) on one volume 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. .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 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.RCK##Set if the file is 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 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.NID##Set if incremental dump (backup) is 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 file data, data written by a user are written back to the disk only when it is removed from the cache. Clear for write-through cache operation. .LM -8 .SKIP The second byte of the file characteristics words is historically known as the system controlled file characteristics. It contains the following flag bits, defined as referenced within the byte: .SKIP .LM +8 .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. .SKIP .INDENT -8 SC.BAD##Set if there is a bad data block in the file. This bit is unimplemented. It is intended for dynamic bad block handling. .SKIP .INDENT -8 SC.DIR##Set if the file is a directory. .SKIP .INDENT -8 SC.ACL##Set if an access control list exists for this file. .SKIP .INDENT -8 SC.CHK##Set if the file header checksum was not computed. If this bit is set, the checksum word must contain the octal value 125252. This "feature" is for small systems that cannot afford the millisecond or two required to compute the header checksum. Its use is strongly discouraged. .SKIP .LM -8 .LM -10 .HL 4 ########2 bytes##Unused .HL 4 H.USE###1 byte##Map Words in Use .LM +10 .SKIP This byte contains a count of the number of map area words currently in use. .LM -10 .HL 4 H.PRIV##1 byte##Accessor Privilege Level .LM +10 .SKIP This byte defines the lowest privilege level at which an accessor must be running to be allowed access to the file. Each privilege level is a two-bit integer; zero is the lowest privilege and 3 is the highest. Privilege levels may be assigned separately to the basic file access modes, using the following bit assignment in this byte: .SKIP Read######Bits 0-1 .BREAK Write#####Bits 2-3 .BREAK Execute###Bits 4-5 .BREAK Delete####Bits 6-7 .SKIP An operating system should map its privilege level coding onto this code in the smoothest manner possible. For example, the four access modes of VMS - user, supervisor, exec, and kernel - are codes 0 through 3, respectively. A system such as RSX-11M which has only two levels (privileged and non-privileged) should map the two onto 3 and 0, respectively. .SKIP Privilege levels are meant to confine access to the contents of file to suitably trustworthy procedures. Thus, a user might be denied the ability to write a record structured file directly (on a virtual block basis), but would be permitted to write the file through the record manager, which would be suitably privileged. .SKIP For a record structured file, an appropriate set of privilege levels is 0,2,0,0, expressed in the order Read - Write - Execute - Delete. .LM -10 .HL 4 H.FOWN##2 bytes##File Owner UIC .LM +10 H.PROG = H.FOWN + 0##Programmer (Member) Number .BREAK H.PROJ = H.FOWN + 2##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 -10 .HL 4 H.FPRO##2 bytes##File Protection Code .LM +10 .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 are defined in Files-11: Read, Write, Execute 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 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. .SKIP Recommended defaults for file protection for an "open shop" are [RWD,RWD,RW,R] (expressed in the order of System - Owner - Group - World, where each letter denotes the presence of that permission). Observe that only files which contain executable programs should have Execute protection enabled. Recommended defaults for a "closed shop" system are [RWD,RWD,R,]. .LM -10 .HL 4 H.BFNU##6 bytes##File Header Back Link .LM +10 .SKIP The back link is the File ID of the directory file containing the primary directory entry of the file. If the file header is an extension header, the back link contains the File ID of the primary header. .LM -10 .HL 4 ########4 bytes##Unused .HL 4 S.HDHD##74 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##20 bytes##File Name .LM +9 .SKIP This area contains the file name in ASCII. A dot separates name from type, and a semicolon separates type from version; both are always present. If the name is shorter than 20 bytes, it is blank-padded; if longer, it is truncated. .LM -9 .HL 4 I.RVNO##2 bytes##Revision Number .LM +9 .SKIP This word contains the revision count of the file in binary. The revision count is the number of times the file has been accessed for write. .LM -9 .HL 4 I.CRDT##8 bytes##Creation Date and Time .LM +9 .SKIP These eight bytes contain the date and time at which the file was created. The time is expressed in the standard internal time format, which is a 64-bit integer representing tenths of microseconds elapsed since midnight, 17 November 1858 ("clunks"). .LM -9 .HL 4 I.RVDT##8 bytes##Revision Date and Time .LM +9 .SKIP The revision date is the date on which the file was last deaccessed after being accessed for write. It is expressed in the same format as I.CRDT above. .LM -9 .HL 4 I.EXDT##8 bytes##Expiration Date and Time .LM +9 .SKIP These eight bytes contain the date and time at which the file becomes eligible to be deleted. The format is the same as that of I.CRDT and I.RVDT above. .LM -9 .HL 4 I.BKDT##8 bytes##Backup Date and Time .LM +9 .SKIP These eight bytes contain the date and time at which the file was last backed up. The format is the same as that of those above. .LM -9 .HL 4 S.IDHD##36 bytes##Size of Ident Area .LM +9 .SKIP This symbol represents the size of the ident area containing all of the above entries. .LM -9 .HL 3 Map Area Description The map area of the file header begins at the word indicated by H.MPOF. 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 allocated to 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. Thus, each retrieval pointer maps virtual blocks j through (j+n) into logical blocks k through (k+n), where j is the total number plus one of virtual blocks represented by all preceding retrieval pointers 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. Observe that j, k, and (n+1) must always be integer multiples of the volume cluster factor. If the LBN field of a retrieval pointer contains all ones (i.e., points to block (2**22)-1 or (2**32)-1, then that retrieval pointer represents an unallocated portion of a sparse file. The count field then describes the number of unallocated virtual blocks in the normal manner. There are four formats of retrieval pointers, each identified by escape codes. The different formats may be intermixed within a file header. .SKIP 2 .TEST PAGE 5 Format 0: Two bytes .SKIP .LM +20 .NO FILL .NO JUSTIFY +----+---------------+ | 00 | Placement | +----+---------------+ .JUSTIFY .FILL .LM -20 .SKIP Format 0 is used to store placement data in the file header. It describes the placement control supplied with the allocation that created the following retrieval pointer, allowing the file placement to be replicated when the file is copied or backed up and restored. Coding of the placement data is undefined. Format 0 is identified by bits 15 and 14 of the first word being 00. .SKIP 2 .TEST PAGE 7 Format 1: Four bytes .SKIP .LM +20 .NO FILL .NO JUSTIFY +----+------+-----------+ | 01 | High | Count | +----+------+-----------+ | Low order LBN | +-----------+-----------+ .JUSTIFY .FILL .LM -20 .SKIP Format 1 provides an 8-bit count field and a 22-bit LBN field. It is therefore capable of representing a group of up to 256 blocks on a volume up to (2**22) blocks in size. Format 1 is identified by bits 15 and 14 of the first word being 01. .SKIP 2 .TEST PAGE 9 Format 2: Six bytes .SKIP .LM +20 .NO FILL .NO JUSTIFY +----+------+-----------+ | 10 | Count | +----+------+-----------+ | LBN | + -+- -+ | LBN | +-----------+-----------+ .JUSTIFY .FILL .LM -20 .SKIP Format 2 provides a 14-bit count field and a 32-bit LBN field. It is therefore capable of representing a group of up to 16,384 blocks on a volume up to (2**32) blocks in size. Format 2 is identified by bits 15 and 14 of the first word being 10. .SKIP 2 .TEST PAGE 11 Format 3: Eight bytes .SKIP .LM +20 .NO FILL .NO JUSTIFY +----+------+-----------+ | 11 | Count, high | +----+ -+- -+ | Count, low order | +-----------+-----------+ | LBN | + -+- -+ | LBN | +-----------+-----------+ .JUSTIFY .FILL .LM -20 .SKIP Format 3 provides a 30-bit count field and a 32-bit LBN field. It is therefore capable of representing a group of up to (2**30) blocks on a volume up to (2**32) blocks in size. Format 3 is identified by bits 15 and 14 of the first word being 11. .HL 3 Access Control List This area is reserved for future use by DEC. .HL 3 Reserved Area The reserved area of the file header starts at the word indicated by the byte H.RSOF. This area is not used by standard Files-11 file managers, but is available for use by CSS and special applications. .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. If the bit SC.CHK is set in the system controlled characteristics word H.SCHA, then the checksum has not been computed, and the checksum word must contain the octal value 125252. .HL 4 H.CKSM##2 bytes##Block Checksum .LM +9 .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 -9 .HL 3 File Header Layout The following is a graphic layout of the fields in the file header. .TEST PAGE 9 .SKIP 2 Header Area .SKIP .NO FILL .NO JUSTIFY +-------------------+-------------------+ H.MPOF | Map Area Offset | Ident Area Offset | H.IDOF +-------------------+-------------------+ H.RSOF | Resv. Area Offset | ACL Area Offset | H.ACOF +-------------------+-------------------+ .TEST PAGE 2 | File Segment Number | H.FSEG +-------------------+-------------------+ .TEST PAGE 2 | File Structure Level | H.FLEV +-------------------+-------------------+ .TEST PAGE 2 | File Number | H.FNUM +-------------------+-------------------+ .TEST PAGE 2 | File Sequence Number | H.FSEQ +-------------------+-------------------+ .TEST PAGE 2 | Relative Volume Number | H.FRVN +-------------------+-------------------+ .TEST PAGE 2 | Extension File Number | H.EFNU +-------------------+-------------------+ .TEST PAGE 2 | Extension File Sequence Number | H.EFSQ +-------------------+-------------------+ .TEST PAGE 2 | Extension Relative Volume Number | H.ERVN +-------------------+-------------------+ .TEST PAGE 10 | | H.UFAT +- -+- -+ | | +- -+- -+ / User File Attribute Area / +- -+- -+ | | +- -+- -+ | | +-------------------+-------------------+ H.FCHA .TEST PAGE 4 H.SCHA | System Char's | User Char's | H.UCHA +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 2 | | Unused +-------------------+-------------------+ .TEST PAGE 6 H.PRIV | Access Level | Map Words in Use | H.USE +-------------------+-------------------+ H.FOWN | File Owner UIC | H.PROG +- -+- -+ | | H.PROJ +-------------------+-------------------+ .TEST PAGE 2 | File Protection | H.FPRO +-------------------+-------------------+ .TEST PAGE 6 | | H.BFNU +- -+- -+ | File Header Back Link | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | | Unused +- -+- -+ | | +-------------------+-------------------+ S.HDHD .JUSTIFY .FILL .SKIP 2 .TEST PAGE 11 Ident Area .SKIP .NO FILL .NO JUSTIFY +-------------------+-------------------+ | | I.FNAM +- -+- -+ | | / File Name / | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 2 | Revision Number | I.RVNO +-------------------+-------------------+ .TEST PAGE 8 | | I.CRDT +- -+- -+ | Creation Date | +- -+- -+ | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 8 | | I.RVDT +- -+- -+ | Revision Date | +- -+- -+ | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 8 | | I.EXDT +- -+- -+ | Expiration Date | +- -+- -+ | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 8 | | I.BKDT +- -+- -+ | Backup Date | +- -+- -+ | | +- -+- -+ | | +-------------------+-------------------+ S.IDHD .JUSTIFY .FILL .SKIP 2 .TEST PAGE 11 Map, ACL and Reserved Areas .SKIP .NO FILL .NO JUSTIFY +-------------------+-------------------+ | | +- -+- -+ | | / Retrieval Pointers / | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 8 | | +- -+- -+ | | / Access Control List / | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 10 | | +- -+- -+ | | / Reserved Area / | | +- -+- -+ | | +-------------------+-------------------+ | 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 Two Level Directory Hierarchy Implementations of Files-11 on PDP-11 systems all support a two-level directory hierarchy which is tied in with the user identification mechanism of the operating system. Each UIC known to the system is associated with a user file directory (UFD). References to files that do not specify a directory are generally defaulted to the UFD associated with the user's UIC. The syntax used to refer to UICs is the same as that used to identify the directory in a file name string. The construct "[g,m]" refers to group number g, member number n. All UFDs are listed in the volume's master file directory (MFD) under a file name constructed from the directory string. A string of "[g,m]" associates with a directory name of "gggmmm.DIR;1", where ggg and mmm are g and m padded to three characters 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 structure; rather, it is a convenient cataloging system applied by the operating system. 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 3 Multi-Level Directory Hierarchy New implementations of Files-11 use a multi-level directory hierarchy. In this scheme, the first level below the MFD is referred to as the user file directory (UFD) and subsequent levels are referred to as sub-file directories (SFDs). Users are identified at the command level by ASCII names; the system translates user names into UICs internally. Thus, MFD entries correspond to ASCII user names. A directory specifier has the format "[name1.name2.name3 ...]". Each name in the list translates to a directory file name of the form "name.DIR;1" and is searched for in the current directory level. Observe that the directory protocol is not tied to the structure level of the disk. Thus, new systems must always handle the "[g,m]" protocol, which maps to a UFD name of "gggmmm.DIR;1" and provides only two levels of directory. Old systems may not be able to handle volumes written with multi-level directories. .HL 3 Multi-Volume Directory Structure In a volume set, the MFD for all user files on the volume set is the MFD of relative volume 1. Its entries can point to UFDs located on any volume in the set, the entries of which in turn may point to files and subdirectories on any volume in the set. The MFDs of remaining volumes in the set list only the reserved files on each volume. The assignment of volumes to specific directories and files is not covered by this specification. Different systems may implement different policies to trade off factors such as performance, reliability and separability. Optimizing for performance, for example, usually means scattering the files as randomly as possible across the volume set to make the most use of the available multiple positioners. Maximum separability (the ability to make use of only part of the volume set) is achieved by locating files on the same volumes as their directories, and possibly by entering the directories in the MFDs of the volumes on which they reside. .HL 2 Directory Structure A directory is a contiguous file, organized as a sequential file with variable length records, with the attribute set that records do not cross block boundaries, and no carriage control attributes. Directory entries within each block are packed together to conform to the variable length record format; a -1 byte count signals the end of records for that block. The entries in a directory are sorted alphabetically, permitting the use of an optimized search. Entries which are multiple versions of the same name and type are arranged in order of decreasing version number to optimize version related operations. Each directory record consists of the following: .SKIP 2 .NO FILL .NO JUSTIFY .TEST PAGE 7 +-------------------+-------------------+ | Record Byte Count | +-------------------+-------------------+ | Version Limit | +-------------------+-------------------+ | Name Byte Count | Flags | +-------------------+-------------------+ .TEST PAGE 8 | | +- -+- -+ | | / File Name String / | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 8 | | +- -+- -+ | | / Value Field / | | +- -+- -+ | | +-------------------+-------------------+ .JUSTIFY .FILL .SKIP 2 .LM +9 .INDENT -9 Count####This two-byte field is the standard byte count field of a variable length record. .SKIP .INDENT -9 Limit####This word contains the maximum number of versions to be retained for this name and type. An attempt to enter more versions than the limit results in deletion of the least recent version or an error return, at the implementing system's option. .SKIP .INDENT -9 Flags####This byte contains the type code of the directory entry and assorted flag bits. The type code is contained in the three low bits of the flags byte. It is one of the following values: .SKIP .LM +8 .INDENT -8 DV.FID##The value field is a list of version numbers and 48-bit File IDs. .SKIP .INDENT -8 The following flag bits are defined: .SKIP .INDENT -8 DF.PRV##Set if the preceding directory record contains the same name and type as this one. .SKIP .INDENT -8 DF.NXV##Set if the next directory record contains the same name and type as this one. .LM -8 .SKIP .INDENT -9 Name#####This field contains the file name and type in ASCII, separated by a dot. The dot is present even if name, type, or both are null. Only upper case alphabetic and numeric characters may be present in the name and type. If the length of the name is odd, it is padded with a single null. .SKIP .INDENT -9 Value####This field contains the "value" of the directory entry; i.e., the information returned to the user from a lookup operation. If the directory record is a File ID list (type field is DV.FID), the value field is a list of version numbers and corresponding File IDs, appearing in descending order by version number. The number of entries in the list is deduced from the record byte count. .LM -9 .SKIP 2 .NO FILL .NO JUSTIFY .TEST PAGE 9 +-------------------+-------------------+ | Version Number | +-------------------+-------------------+ | | +- -+- -+ | File ID | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 11 | Version Number | +-------------------+-------------------+ | | +- -+- -+ | File ID | +- -+- -+ | | +-------------------+-------------------+ ... ... ... .TEST PAGE 8 +-------------------+-------------------+ | Version Number | +-------------------+-------------------+ | | +- -+- -+ | File ID | +- -+- -+ | | +-------------------+-------------------+ .JUSTIFY .FILL .SKIP 2 .LM +9 .INDENT -9 Version##This word contains the version number of the directory entry in binary. Version numbers must lie in the range 1 to 32767. .SKIP .INDENT -9 File#ID##These three words are the File ID that the directory entry points to. .LM -9 .COMMENT .COMMENT ----------------------------------------------------------------- .HL 1 Reserved Files .COMMENT ----------------------------------------------------------------- .COMMENT Clearly, any file system must maintain some data structure on the medium which is used to control the file organization. In Files-11 these data are kept in several files. These files are created when a new volume is initialized. They are unique in that their File IDs are known constants. Note, however, that the relative volume number used when accessing one of these files depends upon the context. The exact number of these files which are present on a particular volume may vary; however, at least five must be present. All of these files are non-deletable. These files have the following uses: File ID 1,1 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 is the storage bitmap file. It is used to control the allocation of logical blocks on the volume. File ID 3,3 is the bad block file. It is a file containing all of the known bad blocks on the volume. File ID 4,4 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 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. File ID 6,6 is the volume set list file. If this volume is relative volume one of a tightly coupled volume set, this file contains a list of the labels of all volumes in the set. File ID 7,7 is the standard continuation file. If this volume is part of a loosely coupled volume set, this file contains the first segment of the portion of the multi-volume file that resides on this volume. File ID 8,8 is the backup journal file. This file is used to log and control the use of an incremental backup system. File ID 9,9 is the pending bad block log file. This file contains a list of suspected bad blocks on the volume that have not yet been turned over to the bad block file. More File IDs may be reserved in the future; users should not make any assumptions about the values of user created File IDs. .HL 2 Index File The index file is File ID 1,1. 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. This file has the FCS record format of 512-byte fixed length records without carriage control. .HL 3 Bootstrap Block Virtual block 1 of the index file is the volume's boot block. It is almost 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. If block 0 of a volume is bad, it is permissible to map virtual block 1 of the index file to some other block. In this case, obviously, the volume cannot be used as a system volume. .HL 3 Home Block Virtual block 2 of the index file is the volume's home block. 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. The home block is located on the first good block of the home block search sequence. The search sequence is of the form .SKIP 1 + (n * delta), where n = 0, 1, 2, 3 ... The home block search delta is computed from the geometry of the volume such that, if the volume is viewed as a three-dimensional space, the search sequence travels approximately down the diagonal of the space. Since volume failures tend to occur across one dimension, this minimizes the chance of a single failure destroying both home blocks of the volume. The search delta is computed from the volume geometry expressed in sectors, tracks (surfaces) and cylinders according to the following rules. .SKIP 2 .LM +10 .NO FILL .NO JUSTIFY Geometry Delta s * 1 * 1 1 1 * t * 1 1 1 * 1 * c 1 s * t * 1 s+1 s * 1 * c s+1 1 * t * c t+1 s * t * c (t+1)*s+1 .JUSTIFY .FILL .LM -10 .SKIP 2 In most cases, the home block is located on LBN 1. .HL 3 Cluster Filler If v, the cluster factor of the volume, is greater than 1, the next (v*2)-2 blocks of the index file are copies of the home block used to fill out the first two clusters of the index file. Note that, for cluster factors greater than 1, this results in a wasted disk cluster. The benefit of this technique is a much simpler rule for finding the VBN of interesting parts of the index file. .HL 3 Backup Home Block The backup home block is a second copy of the home block located farther down the home block search sequence. It permits use of the volume even if the primary home block is destroyed. In general, the backup home block should be allocated on the second good block of the search sequence. If it is not, then all preceding blocks on the sequence must not be available for allocation. This prevents the situation of a malicious user constructing a counterfeit index file, which would be used if the primary home block ever went bad. The cluster which contains the backup home block is mapped into the index file as virtual blocks (v*2)+1 through (v*3), where v is the volume cluster factor. Observe that the backup home block may be located anywhere within this cluster, because there is no hard and fast relationship between the cluster factor and the volume's track and cylinder boundaries. The entire cluster is therefore filled out with copies of the home block. .HL 3 Backup Index File Header The next cluster of the index file contains a backup copy of the index file header, so that data on the volume can be recovered if the index file header goes bad. The cluster occupies virtual blocks (v*3)+1 through (v*4), where v is the volume cluster factor. The LBN of the backup index file header is stored in location H.IHLB in the home block. The backup index file header occupies the first block of this cluster; the remaining blocks are not used and their contents are undefined. .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 (v*4)+1 of the index file and continues through VBN (v*4)+m, where m is the number of blocks in the bitmap, and v is the storage map cluster factor. 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 (v*4)+m+n, where m is the number of blocks in the index file bitmap, and v is the storage map cluster factor. The FCS end-of-file mark for the index file is located at the last file header ever used. All header blocks located before the EOF are subject to validation when used to create a new file. If the block contains garbage, the new header is assigned a file sequence number of 1, being the first use of the header block. If the block contains a deleted file header, the new header is assigned a sequence number one higher than that contained in the block. A block containing a valid file header must never be used to create a new file, even if it is marked free in the index file bitmap. This prevents files from being lost if bits are dropped in the bitmap. Index file blocks beyond the EOF are assumed to contain garbage, for the purpose of creating new file headers. .HL 3 Index File Layout The following is a sketch of the blocks in the index file. Observe that this illustration assumes a storage map cluster factor greater than 2. .SKIP 2 .NO FILL .NO JUSTIFY .TEST PAGE 11 +---------------------------------------+ --+ | Boot Block | | +---------------------------------------+ | | Home Block | | +---------------------------------------+ | | | | Cluster 1 /-- --/ | | More Home Blocks | | /-- --/ | | | | +---------------------------------------+ --+ .TEST PAGE 6 | | | /-- --/ | | More Home Blocks | | Cluster 2 /-- --/ | | | | +---------------------------------------+ --+ .TEST PAGE 2 | Backup Home Block | | +---------------------------------------+ | .TEST PAGE 6 | | | /-- --/ | Cluster 3 | More Home Blocks | | /-- --/ | | | | +---------------------------------------+ --+ .TEST PAGE 2 | Backup Index File Header | | +---------------------------------------+ | .TEST PAGE 6 | | | /-- --/ | Cluster 4 | Unused and Undefined | | /-- --/ | | | | +---------------------------------------+ --+ .TEST PAGE 2 | Index File Bitmap | | +---------------------------------------+ | .TEST PAGE 6 | | | /-- --/ | Contiguous | First 16 File Headers | | /-- --/ | | | | +---------------------------------------+ --+ .TEST PAGE 6 | | /-- --/ | Lots More File Headers | /-- --/ | | +---------------------------------------+ .JUSTIFY .FILL .HL 3 Home Block Details The following is a detailed description of the home block. Note that all copies of the volume's home block contain the same data, with the exception of the cells containing the block's VBN and LBN. 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 HMBL2$, 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.HBLB##4 bytes##Home Block LBN .LM +9 .SKIP This doubleword contains the logical block number of this particular copy of the home block. .LM -9 .HL 4 H.AHLB##4 bytes##Alternate Home Block LBN .LM +9 .SKIP This doubleword contains the LBN of the volume's secondary home block. One may determine, when scanning the home block sequence, whether the block read is the primary or secondary home block by comparing H.HBLB and H.AHLB. This value must be nonzero for a valid home block. .LM -9 .HL 4 H.IHLB##4 bytes##Backup Index File Header LBN .SKIP .LM +9 This doubleword contains the LBN on which the backup index file header is located. This value must be nonzero for a valid home block. .LM -9 .HL 4 H.VLEV##2 bytes##Volume Structure Level .LM +9 .SKIP The volume structure level and version are used to identify different versions of Files-11 as they affect the structure of all parts of the volume except 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 volume. .SKIP This document describes structure level 2 of Files-11. The high byte of H.VLEV must contain 2. The low byte contains the version number, which must be greater than or equal to 1. The version number is incremented when compatible additions are made to the Files-11 structure that may be safely ignored by an old version of the file system. This document describes version 1 of structure level 2. .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. This value is also referred to as the volume cluster factor. .LM -9 .HL 4 H.HBVB##2 bytes##Home Block VBN .SKIP .LM +9 This word contains the virtual block number that the cluster containing the copy of the home block occupies in the index file. This value must be nonzero for a valid home block. .LM -9 .HL 4 H.AHVB##2 bytes##Backup Home Block VBN .SKIP .LM +9 This word contains the virtual block number that the cluster containing the secondary home block occupies in the index file. The content of this word is (v*2)+1, where v is the storage map cluster factor. .LM -9 .HL 4 H.IHVB##2 bytes##Backup Index File Header VBN .SKIP .LM +9 This word contains the virtual block number that the backup index file header occupies in the index file. The content of this word is (v*3)+1, where v is the storage map cluster factor. .LM -9 .HL 4 H.IBVB##2 bytes##Index File Bitmap VBN .SKIP .LM +9 This word contains the starting virtual block number of the index file bitmap. The content of this word is (v*4)+1, where v is the storage map cluster factor. .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. This value must be non-zero for a valid home block. .LM -9 .HL 4 H.FMAX##4 bytes##Maximum Number of Files .LM +9 .SKIP This doubleword contains the maximum number of files that may be present on the volume at any time. This value must be greater than the contents of H.RSVF for the home block to be valid. If the maximum number of files is less than 65,536, then the third word of File IDs referencing files on this volume is simply the relative volume number, and the volume set of which this volume is a member may contain up to 65,535 volumes. If the maximum number of files is greater than or equal to 65,536, then the high byte of the third word of File IDs is the high byte of the file number, and the volume set may consist of up to 255 volumes. Under no circumstances may the maximum number of files be greater than (2**24)-1. .LM -9 .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. This value must be non-zero for a valid home block. .LM -9 .HL 4 H.RSVF##2 bytes##Number of Reserved Files .LM +9 .SKIP This word contains the number of reserved files on the volume. The file sequence number of each reserved file is always equal to its file number. Reserved files may not be deleted. This word must contain a minimum value of 5 to be valid. .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.RVN##2 bytes##Relative Volume Number .LM +9 .SKIP This word contains the relative volume number that this volume is assigned in a volume set. If the volume is not part of a volume set, this word contains zero. .LM -9 .HL 4 H.NVOL##2 bytes##Number of Volumes .LM +9 .SKIP This word contains the total number of volumes in this volume set if the contents of H.RVN is 1 (i.e., if this volume is the first volume of the set). Otherwise, this word contains zero. .LM -9 .HL 4 H.VCHA##2 bytes##Volume Characteristics .SKIP .LM +9 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##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##Set if the volume may not be attached, i.e., reserved for exclusive use by one task or user. .SKIP .INDENT -8 CH.RCK##Set if the volume is to be read checked. All block reads done on this volume, for both data and file structure, are performed with a read, read-compare to insure data integrity. .SKIP .INDENT -8 CH.WCK##Set if the volume is to be write checked. All block writes done on this volume, for both data and file structure, are performed with a write, read-compare to insure data integrity. .LM -8 .LM -9 .HL 4 H.VOWN##4 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 .HL 4 ########4 bytes##Unused .SKIP .HL 4 H.VPRO##2 bytes##Volume Protection Code .LM +9 .SKIP This word contains the protection code for the entire volume. All operations on all files on the volume must pass both the volume and the file protection check to be permitted. Accessors of the volume are categorized into system, owner, group and world with respect to the volume owner UIC in the same manner as for file protection. Each category is controlled by a four bit field. The four access modes are bit encoded as follows: .SKIP .LM +8 VP.RDV##Deny reading files .BREAK VP.WRV##Deny writing existing files .BREAK VP.CRE##Deny creating files .BREAK VP.DEL##Deny deleting files .LM -8 .LM -9 .HL 4 H.DFPR##2 bytes##Default File Protection .LM +9 .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 -9 .HL 4 ########2 bytes##Unused .HL 4 H.CHK1##2 bytes##First Checksum .LM +9 .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. .LM -9 .SKIP .HL 4 H.VDAT##8 bytes##Volume Creation Date .LM +9 .SKIP This area contains the date and time that the volume was initialized. It is in the same binary format as that used in the file header. .LM -9 .HL 4 H.WISZ##1 byte##Default Window Size .SKIP .LM +9 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 -9 .HL 4 H.LRUC##1 byte##Directory Pre-Access Limit .LM +9 .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 -9 .HL 4 H.FIEX##2 bytes##Default File Extend .LM +9 .SKIP This word 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 -9 .HL 4 ########388 bytes##Unused .HL 4 H.SNAM##12 bytes##Structure Name .LM +9 .SKIP This area contains the ASCII name of the volume set to which this volume belongs, padded out to 12 bytes with spaces. If this volume is not a member of a volume set, this area is filled with blanks. .LM -9 .HL 4 H.INDN##12 bytes##Volume Name .LM +9 .SKIP This area contains the volume name in ASCII. It is padded out to 12 bytes with spaces. It is placed here in accordance with the proposed volume identification standard. .LM -9 .HL 4 H.INDO##12 bytes##Volume Owner .SKIP .LM +9 This area contains an ASCII string identifying the owner of the volume. The area is padded out to 12 bytes with trailing spaces. It is placed here in accordance with the proposed volume identification standard. .LM -9 .HL 4 H.INDF##12 bytes##Format Type .LM +9 .SKIP This field contains the ASCII string "DECFILE11B" padded out to 12 bytes with spaces. It identifies the volume as being of Files-11 format, structure level 2. It is placed here in accordance with the proposed volume identification standard. .LM -9 .HL 4 ########2 bytes##Unused .HL 4 H.CHK2##2 bytes##Second Checksum .LM +9 .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 same algorithm as the file header checksum. .LM -9 .HL 3 Home Block Layout .SKIP .NO FILL .NO JUSTIFY .TEST PAGE 5 +-------------------+-------------------+ | LBN of This Block | H.IBLB +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | LBN of Secondary Home Block | H.AHLB +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | LBN of Secondary Index File Header | H.IHLB +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | Volume Structure Level | H.VLEV +-------------------+-------------------+ | Storage Bitmap Cluster Factor | H.SBCL +-------------------+-------------------+ .TEST PAGE 4 | VBN of This Block | H.HBVB +-------------------+-------------------+ | Backup Home Block VBN | H.AHVB +-------------------+-------------------+ .TEST PAGE 4 | Backup Index Header VBN | H.IHVB +-------------------+-------------------+ | Index File Bitmap VBN | H.IBVB +-------------------+-------------------+ .TEST PAGE 4 | Index File Bitmap LBN | H.IBLB +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | Maximum Number of Files | H.FMAX +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | Index File Bitmap Size | H.IBSZ +-------------------+-------------------+ | Number of Reserved Files | H.RSVF +-------------------+-------------------+ .TEST PAGE 4 | Disk Device Type | H.DVTY +-------------------+-------------------+ | Relative Volume Number | H.RVN +-------------------+-------------------+ .TEST PAGE 4 | Number of Volumes in Set | H.NVOL +-------------------+-------------------+ | Volume Characteristics | H.VCHA +-------------------+-------------------+ .TEST PAGE 4 | Volume Owner UIC | H.VOWN +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | | Unused +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | | Unused +-------------------+-------------------+ | First Checksum | H.CHK1 +-------------------+-------------------+ .TEST PAGE 4 | Volume Protection | H.VPRO +-------------------+-------------------+ | Default File Protection | H.DFPR +-------------------+-------------------+ .TEST PAGE 8 | | H.VDAT +- -+- -+ | Volume Creation Date | +- -+- -+ | | +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 H.LRUC | Directory Limit | Def. Window Size | H.WISZ +-------------------+-------------------+ | Default File Extend | H.FIEX +-------------------+-------------------+ .TEST PAGE 6 | | Unused +- -+- -+ / / +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 12 | | H.SNAM +- -+- -+ | | +- -+- -+ | Structure Name | +- -+- -+ | | +- -+- -+ | | +- -+- -+ | | +-------------------+-------------------+ .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 2 Storage Bitmap File The storage bitmap file is File ID 2,2. 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. This file has the FCS record format of 512-byte fixed length records, with no carriage control. The end-of-file mark is positioned to point to the last block used. The storage bitmap file must be contiguous. .HL 3 Storage Control Block Virtual block 1 of the storage bitmap is the storage control block. It contains summary information about the volume. Note that implementation of some items in the storage control block may require it to be written at mount and dismount. .HL 4 C.VLEV##2 bytes##Storage Map Structure Level .SKIP .LM +9 This word contains the structure level of the storage control block. The high byte contains the value 2 to indicate Files-11 structure level 2. The low byte contains the version number, which must be greater than or equal to 1. .LM -9 .HL 4 C.SBCL##2 bytes##Storage Map Cluster Factor .SKIP .LM +9 This word contains the storage map cluster factor of the volume. Its content is identical to the content of H.SBCL in the home block. It is placed here for convenience. .LM -9 .HL 4 C.VSIZ##4 bytes##Volume Size .SKIP .LM +9 This doubleword contains the volume size expressed in logical blocks. .LM -9 .HL 4 C.BLKF##4 bytes##Blocking Factor .SKIP .LM +9 This doubleword contains the blocking factor of the volume, i.e. the number of physical blocks or sectors that make up one logical block. .LM -9 .HL 4 C.SECT##4 bytes##Sectors per Track .SKIP .LM +9 This doubleword contains the number of logical blocks in each track of the volume. .LM -9 .HL 4 C.TRAK##4 bytes##Tracks per Cylinder .SKIP .LM +9 This doubleword contains the number of tracks contained in each cylinder of the volume. .LM -9 .HL 4 C.CYLN##4 bytes##Number of Cylinders .SKIP .LM +9 This doubleword contains the number of cylinders on the volume. This and the preceding three quantities are present to assist optimized allocation of space on the volume. .LM -9 .HL 4 C.STAT##2 bytes##Status Word .SKIP .LM +9 This word contains the following status bits: .SKIP .LM +8 .INDENT -8 CS.TRN##Volume in transition. Set if the volume may be in an inconsistent state because it was not dismounted properly. A system which does write-on-replace caching of the storage map, for example, should set this bit on mount and clear it on dismount. .LM -8 .LM -9 .HL 4 ########488 bytes##Unused .HL 4 C.CKSM##2 bytes##Block Checksum .SKIP .LM +9 This word contains the block checksum. It is computed using the same algorithm as the file header checksum. .LM -9 .HL 3 Storage Control Block Layout .SKIP .NO FILL .NO JUSTIFY .TEST PAGE 3 +-------------------+-------------------+ | Structure Level | C.VLEV +-------------------+-------------------+ .TEST PAGE 2 | Storage Map Cluster Factor | C.SBCL +-------------------+-------------------+ .TEST PAGE 4 | Volume Size in Blocks | C.VSIZ +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | Blocking Factor | C.BLKF +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | Sectors per Track | C.SECT +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | Tracks per Cylinder | C.TRAK +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 4 | Cylinders on Volume | C.CYLN +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 2 | Volume Status | C.STAT +-------------------+-------------------+ .TEST PAGE 6 | | Unused +- -+- -+ / / +- -+- -+ | | +-------------------+-------------------+ .TEST PAGE 2 | Block Checksum | C.CKSM +-------------------+-------------------+ .JUSTIFY .FILL .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 allocatable clusters on the volume rounded up to the next integer multiple of 4096. Each cluster contains v logical blocks, where v is the storage map cluster factor (also referred to as the volume cluster factor) contained in home block location H.SBCL. 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 blocks (j*v) through ((j*v)-1) of the volume; if the bit is set, the blocks are free; if clear, the blocks are 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. Rounding the storage map file up to the next multiple of the volume cluster factor may result in unused blocks at the end of the file. The FCS end-of-file mark points to the last block used. .HL 2 Bad Block File The bad block file is File ID 3,3. 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. This file has the FCS record format of 512-byte fixed length records with no carriage control. The end-of-file mark may be placed as the operating system's bad block handling strategy finds useful. Volume initialization should place the EOF at the end of the bad blocks found during initialization. At all times, the EOF should at least point past the bad block descriptor data described below. This ensures that the bad block data is preserved for future reinitializations of the volume. .HL 3 Factory Bad Block Descriptor On disks such as the RK07 and RM03, which have factory generated last track bad block data, the first several clusters of the bad block file should include the last track of the volume. This track contains redundantly recorded descriptions of the bad blocks on the volume as described in DEC STD 144, "Disk Standard for Recording and Handling Manufacturing Detected Bad Sectors". .HL 3 Software Bad Block Descriptor On disks that do not have factory last track bad block data, the first cluster of the bad block file contains 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 block scan program or diagnostic. The software bad block descriptor is most of a Files-11 structure level 1 header map area. The first two bytes contain the constants 1 and 3, respectively. The third byte contains the number of words that contain data. The fourth byte contains the number of words available for bad block data. The last word of the block contains the usual additive checksum. The retrieval pointers are structure level 1 pointers as described below. .HL 3 Bad Block Descriptor Layout .SKIP .NO FILL .NO JUSTIFY .TEST PAGE 15 +-------------------+-------------------+ | 3 | 1 | +-------------------+-------------------+ | Map Words Avail. | Map Words in Use | +-------------------+-------------------+ | | +- -+- -+ | | / Retrieval Pointers / | | +- -+- -+ | | +-------------------+-------------------+ | Block Checksum | +-------------------+-------------------+ .JUSTIFY .FILL .SKIP Each retrieval pointer is four bytes in length. 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. .SKIP .LM +20 .NO FILL .NO JUSTIFY +-----------+-----------+ | Count | High | +-----------+- -+ | Low order LBN | +-----------+-----------+ .JUSTIFY .FILL .LM -20 .HL 2 Master File Directory The master file directory (MFD) is File ID 4,4. 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 reserved files, plus whatever the user chooses to enter. The format of the MFD is the same as all directory files. The MFD contains entries for all user file directories. .HL 2 Core Image File The core image file is File ID 5,5. 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. This file has the FCS record format of 512-byte fixed length records with no carriage control. The end-of-file mark is positioned to point to the physical end of file. .HL 2 Volume Set List The volume set list is File ID 6,6. It is listed in the MFD as VOLSET.SYS;1. It is used only on relative volume one of a tightly coupled volume set. It contains a list of the volume labels of the volumes contained in the volume set. The format of this file is FCS 64-byte fixed length records with implied carriage control. The first 12 bytes of record 1 contain the structure name of the volume set. The first 12 bytes of record n contain the volume label of relative volume (n-1). The remaining 52 bytes of each record are reserved for future use. .HL 2 Continuation File The standard continuation file is File ID 7,7. It is listed in the MFD as CONTIN.SYS;1. It is used as the extension File ID when a file crosses from one volume of a loosely coupled volume set to another. The purpose of this reserved File ID is to allow a multi-volume file to be written sequentially with only one volume mounted at a time. Ordinarily, when a file is extended to another volume, the new header must be created first to obtain the new File ID before the extension linkage in the current header can be written. The use of this reserved File ID allows the extension linkage to be written with a known constant before the next volume is even on line. .HL 2 Backup Log File The backup log file is File ID 8,8. It is listed in the MFD as BACKUP.SYS;1. This file contains a history of volume and incremental backups performed on the volume. The format of this file is FCS 64-byte fixed length records. The content is undefined. .HL 2 Pending Bad Block Log File The pending bad block log file is File ID 9,9. It is listed in the MFD as BADLOG.SYS;1. This file contains a list identifying suspected bad blocks that are not currently contained in the volume bad block file. The format of this file is FCS 16-byte fixed length records. Each record represents one bad block, and has the following format: .HL 3 Pending Bad Block Record Layout .SKIP .NO FILL .NO JUSTIFY .TEST PAGE 17 +-------------------+-------------------+ | | P.FID +- -+- -+ | File ID containing bad block | +- -+- -+ | | +-------------------+-------------------+ P.CNT | Error Count | Flags | P.FLGS +-------------------+-------------------+ | VBN within file | P.VBN +- -+- -+ | | +-------------------+-------------------+ | LBN | P.LBN +- -+- -+ | | +-------------------+-------------------+ .JUSTIFY .FILL .SKIP The following bits are defined in the flags byte: .SKIP .LM +8 .INDENT -8 PF.RDE##Set if a read error has occurred on this block. .INDENT -8 PF.WRE##Set if a write error has occurred on this block. .LM -8