[Info-vax] ODS-5 data/file recovery

[Hein RMS van den Heuvel]

On Saturday, February 16, 2013 8:35:25 PM UTC-5, Stephen Hoffman wrote:
> On 2013-02-17 01:07:59 +0000, MG said:
> 
> >     $ MCR $1$DKA1:[data_recovery]FLORIAN $1$DKA6: [0,0]OLSYS.ZIP
> >     *** not a Files-11 Structure Level 2 disk volume
> 
> > to rewrite or help me rewrite it to make it suitable for ODS-5...
> 
> Why don't you do that?

Because it is a scary prospect.
But Marco, it might be as simple as changing one error exit
to print a warning instead.
ODS-5 and ODS-2 are so close that for the purpose of your exercise you may well be able to treat them equally. So search for the error message and remove the exit following the print, or print instead of exit with status.
Not that I think Florian will do much for you. Just saying.

I big money was at stake, I would probably use BACK/PHY to an LD device such that I could more readily use a file tool (virtual ios: search, perl,..) on the image versus a tool that can do logical IOs.

Mind you DUMP and DCL can access a disk mounted foreign just fine.
Out of curiosity I tried patching an ODS-5 marker to ODS-2, but I'm afraid to report involves more than one quick update. 
Maybe folks like to see how you can ALMOST do this.

The first structure level indicator is in the home block as byte 12, and the block is double-mapped as VBN-2 in INDEXF.SYS so...
First create a disk to play with:


$ sysman io connect mda2: /noadap /driver=sys$mddriver
$ init/size=2000 mda2 test /stru=5
$ moun/sys mda2: test test
%MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
$ dism test
$ init/size=2000 mda2 test /stru=5/clus=7
$ moun/sys mda2: test test
%MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
$ dump/bloc=(coun=1,start=2)/head/wid=80  TEST:[000000]INDEXF.SYS;1
Map area ...     Retrieval pointers
        Count:         21        LBN:         35
        Count:          7        LBN:         91

That "35" (0x023) is critical... is tells us that he homeblock is LBN 36 (0x024)in this example.

00070501 0000005B 00000031 00000024  ... 00000
0000007D 00000046 001D0016 000F0002  ... 00010

See that "0501" That's ODS-5 version 1
The 0x24 is pointing back to the block itself, 
as is the 0002 (vbn) on offset 0x10
The 0x31 is pointing to an (one of many) alternate homeblock as is the 0x0F.

So lets's fix that 0501!

$ moun/for mda2:
%MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
$ open/read/write x mda2:
$ x="abcd" ! 4 byte string
$ x[0,32]=36 ! Zap in a binary pattern
$ reca read
$ read/key=&x x home  ! Must defer interpolation using &, not "'''"
$ write sys$output f$fao("!XW",F$CVUI(012*8,16,home)) 
0501  ---> structure
$ write sys$output f$fao("!XW",F$CVUI(510*8,16,home))
5E00  ---> checksum
$ home[012*8,16]=%x0201
$ checksum = F$CVUI(510*8,16,home) - %x0501 + %x0201
$  home[510*8,16]=checksum
$ write sys$output f$fao("!XW",F$CVUI(510*8,16,home))
5B00 ---> new checksum
$ write /upda/symb x home
$ close x
$ dism mda2
$ mount mda2 test test
%MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
$ write sys$output f$getdvi("test:","ods5")
TRUE

Dang!   ... So I went on to patch the first alternate,
and I patched the structure level in the storage control block
(offset 0 in VBN 1 of storage bitmap, which is vbn (cluster*4+1) in indexf.sys)
Still no luck, so I gave up but not after looking for obvious other places:
$ DUMP/BLOCK=COUNT=1000/OUT=TMP.TMP
$ SEARCH TMP.TMP "0501 "," 0501",BLOCK
:

Anyway, I ran out of time on that, but maybe the method is of interest.

The other suggestion i was going to make is made already, but let me echo:
Make a much similar file as the original and dump,poke and prod that to see patterns and to expected picture.  
Steven S might know enough about ZIP files internal to confirm how (im)possible your mission is.

For example back to my index file example... each bucket has a VBN sample word, which was enough for me to string them together in the right order!

Cheers,
Hein