Recreating a CMS library

[BrianT_1]

I have a CMS library whose control file 01CMS.CMS contains a forced error. The library continues to work, I can see all the elements, I can operate on them, and everything. VERIFY also succeeds. The issue is that BACKUP won't handle the library properly because of the forced error. Is there any way to read through a CMS library and recreate it exactly as it is in a new library with all of the generations intact? I realize I can fetch all the latest generations and put them in a new library, but then the history and prior generations are gone.
--
Brian Tillman

[Jess Goodman]

You can clear a forced error by writing to the block in question. So find the disk block in question by analyzing the VMS error log. Then write a quick program that assigns a channel to the volume and does a SYS$QIOW using function code IO$_READLBLK and a 1 block buffer (ignoring the error status) and then rewrites the buffer with function code IO$WRITELBLK.

[BrianT_1]

Sorry, but that's beyond my skill level.
--
Brian Tillman

[David B Sneddon]

Brian,

Grab the DBS_PATCH package and use the PATCH_DISK
utility to do the read/write that Jess is talking
about...
It is quite simple and I have used it a number of
times.
If you need any assistance with it I am available
at dbsneddon at bigpond dot com

Dave

[Hoff]

Various organizations can assist rebuilding a CMS library; HP and others here have experience with this.

The brute-force approach is to rewrite the bad block, which is what the other replies here point to. The data may well be bad; as mentioned below, the block-level ECC is flagging this.

I'd probably just try to use BACKUP to copy the file, and then RENAME the files around so that the copy was the current file. When the file gets deleted and/or rewritten, the block will be replaced.

There is a disk error here. These might be an occasional lost block, or this disk could be seeing additional problems. And volume shadowing or RAID is the only way to recover a block error.


" BACKUP is telling you that there might well be an error in the data
stored in the specific original disk sector involved -- this flag
indicates that BACKUP was not able to reliably read the data from
the disk, and flags the potential corruption.

Rewriting the faulty disk sector will trigger automatic bad block
recovery, and a good block will replace the faulty block."


"$ HELP/MESSAGE FORCEDERROR

FORCEDERROR, forced error flagged in last sector read

Facility: SYSTEM, System Services

Explanation: This message applies only to devices governed by the mass
storage control protocol (MSCP). The data in this sector is
copied from another sector that had unrecoverable read errors.
This data is written with the Forced Error Indicator set to
show subsequent readers that the data is questionable.

User Action: Be aware that the contents of the sector are only a close
approximation of the data. Use the Backup utility to make a
copy of the original file and recover its contents."

[BrianT_1]

Hoff said:

> I'd probably just try to use BACKUP to
> copy the file, and then RENAME the files
> around so that the copy was the current
> file. When the file gets deleted and/or
> rewritten, the block will be replaced.

So even though BACKUP complains, if the file is actually good, as seems to be indicated by the ability to use the CMS library and to verify the library, that the copied file should work, correct?

[Hoff]

>So even though BACKUP complains, if the file is actually good, as seems to be indicated by the ability to use the CMS library and to verify the library, that the copied file should work, correct?

Anything that reads from that block will get the bad data. (Though I do hesitate to write "gets the same bad data" there. Different readers could well get different bad data.) BACKUP is simply telling you it got bad data. Whether or not the bad data or the bad block is relevant here is another discussion; there are cases where bit errors that don't matter can arise. On the other hand, bit errors can slam you. (The most recent data I've seen on reliability points to an average of three to six of these errors per terabyte, too.)

The above assumes the absence of a BACKUP bug.

[Hoff]

ps: here are two articles I wrote up a while back... The first introduces FORCEDERROR, and the second shows SCSI bad block handling.

http://64.223.189.234/node/1115

http://64.223.189.234/node/838