recovery of unsaved data in vax/vms

[prabir kumar patra]

hi
request help from the expert. iam looking after vax4000-505 with vms6.2 that is maintaining vital live data in a record file stored in data disk. the system of recording is alloting block of 104 with a data-record-file of 0/104 size. the allotment of block increased until itis alloted 25000 block. That time it is saved with actual size of block/alloted block i.e. say data-record-file 24835/25000. the system hanged and therefore rebooted when data record file having 0/12485. after rebooting the data-record-file showing a file as data-recod-file 0/12485.
i have doubt whether i can recover the data but as it is very vital information is there any possibility to recover the unsaved data if it is dumped any where.
i will be thankful if some one help to recover the vital data. there is only single reboot of the system after halting.

[Steven Schweda]

> [...] from the expert [...]

I'm not he, but you might try:

SET FILE /END_OF_FILE

HELP says:

SET

FILE

/END_OF_FILE

Resets the end-of-file (EOF) mark to
the highest block allocated.


> i have doubt whether i can recover the
> data [...]

Same here.

[Steven Schweda]

(If that qualifier exists in VMS V6.2...)

[Robert Gezelter]

Prabir,

As Steven has mentioned, SET FILE/END_OF_FILE is useful, as is SET FILE/ATTRIBUTE.

The challenge is finding the last record written to the file. Records are written to the file more or less in order (there can be some reordering of the writing of individual disk blocks for a variety of reasons).

Resetting the end of file to the absolute end is a start on the process. Finding the actual end of the file is the real challenge. This analysis can be time consuming or not, depending on what was in those disk blocks before they were used and how obvious the actual record contents are. One technique for examining the contents is to use the DUMP utility.

You may seriously need to consider outside assistance, as you have implied [Disclosure: As do others in this forum, my firm does provide such services].

Sorting out the end of the actually written data involves analyzing the actual contents of the file, and can be time consuming. Thus, I would consider outside the scope of what can be done in an ITRC response.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Prabir,

Both the SET FILE qualifiers mentioned in my post are verified as available in Version 6.2.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

If you now the data, just edit the file after set file/end and cut away the garbage at the end (nulls or garbage depending on settings). Then save and check if the file format is still the same (dir/fu).

Wim

[Hein van den Heuvel]

>> > [...] from the expert [...]
> I'm not he, but you might try:
> SET FILE /END_OF_FILE


I am.

And beware that SET FILE/END is one of the most dangerous and destructive commands you can use in these situations UNTIL you made sure to have disabled HIGH WATER MARKING (HWM)

With HWM turned on setting the EOF forces the system to write zeroes over all the block between the last HWM recorded and the new EOF. This may well overwrite valueable data.

Note... since RMS now has exit handlers, this is actually tricky to test on recent OpenVMS versions. I double-checked using a Personal Alpha and stopped the emulator to mimic this. Only takes seconds...

Hope this helps,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting

[Hein van den Heuvel]

Wim wrote>> If you now the data, just edit the file after set file/end and cut away the garbage at the end (nulls or garbage depending on settings).

Personally I MUCH prefer DUMP/BLOC=(STA:x,COU:1) to analyze the current data, and SET FILE/ATTR=(EBK:x,FFB:y) to 'fix' the file to catch as much as possible.
That is... if you survived the SET FILE/END.

Here is a cute (I think :-) experiment.
Running an LD device on a Personal Alpha.
(Yes, that is a container in a container!)

$LD CREATE LDA1.DISK/SIZE=5000
$LD CONNEC LDA1.DISK LDA1:
$INIT LDA1: JUR
$MOUN LDA1: JUR/SYS
$LD TRACE LDA1:
$COPY TMP.TXT LDA1,TT: LDA1:[000000]tmp.tmp
! The TT: makes the copy NOT close the file and wait for input.
! Now crash the system and re-boot:

$ mount/sys lda1 jur
%MOUNT-I-MOUNTED, JUR mounted on _P2$LDA1:
%MOUNT-I-REBUILD, volume was improperly dismounted; rebuild in progress
$DUMP/HEAD/BLOC=COUNT=0 LDA1:[000000]tmp.tmp
Dump of file LDA1:[000000]TMP.TMP;1 on 10-MAR-2009
:
File name: TMP.TMP;1
:
Map area
Retrieval pointers
Count: 12 LBN: 108
Count: 106 LBN: 143
:
$ dump/bloc=(star=143,coun=1) LDA1:
:
Dump of device LDA1: on 10-MAR-2009
:
Logical block number 143 (0000008F), 512 (0200) bytes

0020202D 20434544 3D524555 5353492F 000E0020 2D203633 31303532 2D534D56 VMS-250136 - .../ISSUER=DEC - . 000000

$ set file/end lda1:[000000]tmp.tmp
$ ld trace/reset lda1:
$ dump/bloc=(star=143,coun=1) LDA1:
$ ld show /trace lda1:
I/O trace for device P2$LDA1:
10-MAR-2009 03:47:42.05 on node P2::

Start Time Elaps Pid Lbn Bytes Iosb Function
-------------------------------------------------------------
03:47:35.39 00.00 000000A5 108 6144 NORMAL DSE|ERASE
03:47:35.39 00.00 000000A5 143 54272 NORMAL DSE|ERASE
03:47:35.40 00.00 000000A5 2516 512 NORMAL WRITEPBLK|EXFUNC|DATACHECK
03:47:35.40 00.00 000000A5 2516 512 NORMAL WRITEPBLK|EXFUNC|DATACHECK
03:47:35.40 00.00 000000A5 2516 512 NORMAL WRITEPBLK|EXFUNC|DATACHECK

See that DSE | ERASE... that is a big "OUCH" if the data is valuable.
Let's repeat the same dump, for the same block:

$ dump/bloc=(star=143,coun=1) LDA1:

Dump of device LDA1: on 10-MAR-2009

Logical block number 143 (0000008F), 512 (0200) bytes

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000020


Be careful out there!
Hein.

[Robert Gezelter]

Hein,

Indeed, a good observation. I normally use the SET FILE/ATTRIBUTES to reset the end of file.

Highwater marking is indeed the default on 6.2 (verified). SHOW DEVICE/FULL will disclose that highwater marking is enabled on a particular volume. It is disabled using the SET VOLUME/NOHIGHWATER_MARKING command.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

I'd start by using BACKUP /PHYSICAL or such after this sort of a crash, to get a copy of the data without risking damage during repair. For this specific case, a block-level disk clone operation isn't strictly necessary, but I've also seen cases where the data gets clobbered by some operation that happens during or after the reboot.

One other consideration here that hasn't been mentioned so far is the need to fix this application code. It's badly broken. There are at least two errors here, around how the file is written, and around how the application is not maintaining a journal.

If this is critical data, then it needs to be treated as critical data.

Get somebody that is an expert to look at (and to update) the application code. If this data loss has happened once, then it'll happen again.

And given how old the VAX 4000 model 505 box and OpenVMS VAX V6.2 is, hardware errors and related badness are very likely going to be on the rise.