UPDATE: THe capabilities of this program, and many more, are contained in program OPIND. If you need to hack around on an ODS-1 disk, please see my later blog postings and get a copy of OPIND.
Lately, I've had occasion to do a lot of work on ODS-1 virtual disks on RSX. Specifically, I've been playing around with the contents of the home blocks.
ODS-1 home blocks are the real root of a Files-11 ODS-1 file system. It tells you where the index file is, and that's where all the file headers are.
The home block is located on the second logical block of a disk or virtual disk file. There are provisions in the FIles-11 code for locating it somewhere else, in case block 2 is bad, but really, how likely is that? I've never seen it occur, so I don't worry about it. For my purposes, it's always at block 2.
RSX doesn't really provide any tools for listing the contents of the home block. There's DMP, of course, but, unless you're looking at PDP11 instructions (which naturally is grouped three bits at a time), octal is not the easiest format for looking at the bit contents of numbers. I wrote HOMCHK (home block check), which lists the home block contents in hex (hex allows you to easily see what bits are set or cleared, by inspection, much easier than octal or decimal).
The home block also contains two checksums - one about three quarters of the way into the block, and one at the end of the block. Why are there two checksums? Beats me. Each one of these is the sum of all the preceding words, up to the checksum word. I was experimenting with changing the home block values, which meant that the checksums would need to be updated, to allow the disk file to be mounted as a virtual disk - MOU gets upset when the checksums aren't right. In order to deal with this, I added the ability to HOMCHK to indicate the state of these checksums (good or bad), and to update them if you want, by using the /UP switch. The other supported switch is /DU - it will produce a hex dump of the whole home block..
Anyway...don't use this unless you know what you're doing...it will definitely blast two checksums into block 2 of any file or disk...
Here's the code.....
homchk.mac
To make...
mac homchk=homchk
tkb
TKB>homchk/pr:0=homchk
TKB>/
Enter Options:
TASK=...HCK
LIBR=FCSRES:RO ;optional, can save memory on a busy system
//
Note the use of the /PR:0 switch on the task output file. This builds the task as privileged, but with no mapping of the IO page. This allows the task to do QIOs to a mounted disk, without consuming task address space for the IO page.
To use...
>run HOMCHK
HCK>infile
or install it
>ins HOMCHK
>HCK infile
HOMCHK will work on real disks as well as virtual disks. Be sure and put a colon at the
end of the device spec, or it will think it's a filename.
HCK>du4:
MOUNT allows you to see some of the home block information, if you add /VI, and there is also the HOME command, that both allows you to examine and modify some content of the home block. See HELP.
ReplyDeleteAh, thanks for the info, good to know Again, my RSX11D/IAS background caused another lacuna in my M+ knowledge. I was mainly using this program to do ODS structure level experiments at the time. I was curious when I discovered that VAX/VMS has trouble dealing with large, later ODS-1 disks. While messing with it, I got tired of manually calculating the two checksums every time I did a zap change to the home block. Now, if I was doing these experiments again, I'd use the latest OPIND, which can easily update home blocks and lots of other things. HOMCHK is now only of historical interest (if that).
ReplyDelete