.ap;.nj .c;Recover2 .b .c;ODS-2 Disk Recovery Tools .b .c;Anthony E.#Scandora, Jr. .b .c;921 E.#Parkway Drive .c;Wheaton, IL##60187 .t Recover2 ODS-2 Disk Recovery Tools One Friday afternoon, I got a phone call from a poor soul who had initialized the wrong disk in a cluster, was sorry, and wanted it back. The volume was mounted on another CPU, but VMS let it be initialized, anyway. The system's TU77 had been busted for a few weeks, so the only tape backup was too old to be useful. I looked at Mike Higgins' and Phil Cannon's disk recovery tools from old RSX SIG tapes, but they assumed that the index file was still available. Unlike RSX, which creates a reasonably sized index file by default, VMS just creates a little index file by default and extends it a lot. Fortunately, the initialize command had no arguments in it (except, of course, the wrong device name), so all we had to do was find all of the blocks that were in the old index file and use them to recover their files. What does an index file block look like? I looked in starlet.mlb for a macro describing it, but I couldn't find one (now I feel stupid for forgetting to look in lib.mlb). TSC had a huge manual on the subject, but they didn't want to read it to me over the phone. A long time ago, an ancient ODS-2 document for the PDP-11 fell into my hands. It was worth a shot. Sure enough, it still describes ODS-2. It even names the macro fhdo2$, which is in rsxmac.sml. I translated that macro to VAX macro, and we were in business. I wrote scan2 to read every block on a disk, decide if it could have been in the index file, and if so, write some of the fields (see indexf.dtr) into a file called indexf.seq on a good disk. Then I converted it to indexf.idx, and let Datatrieve analyze it. Good old ODS-2 has back file pointers, which point to files' directory files. We had Datatrieve write a report sorted by back file pointer and file name, which produced a great sigh of relief. The other half of the program, recover2, reads every record in indexf.idx, and for each record that is marked to be recovered, reads a file header by LBN from the dead disk and restores the file to the directory logically named recovered:. That program is driven by recover2.com, which takes two arguments: a directory name and its FID on the dead disk. It calls Datatrieve to mark all files whose back file pointer matches the directory's FID to be recovered, creates the destinatation directory and assigns the logical "recovered" to it, runs recover2, and calls Datatrieve again to change the status of all of the files to be recovered to done. Finally, we marked all unprocessed files to be recovered, and let recover2 put them in syslost. They only had an ancient PDP-11 DTR, which appears to read commands from its terminal, so I had to "mcr dtr @file" to call it. The Datatrieve procedures could be a lot better for VAX Datatrieve. The old DTR uses the size of the pic to decide if comp fields are words or longs. There were no multi-header files on the disk, so recover2 doesn't do them. It could be added. I started to have it create the file with XABs, but it got too complicated. I commented out that code and had it write the header. I think there is code in there for more than 64K files. The high byte of the relative volume is the high byte of a three byte file number. To do it right, the program should be changed to swap the bytes of the relative volume number and use that as the high word of a long file number. This was done on a commercial system, so this SIG tape submission does not contain any of their directories.