I am getting the following error when performing the command "cms show history": "%CMS-F-BUG, there is something wrong with CMS or something it calls", "-CMS-F-INVHISREC, Invalid history record", "-SYSTEM-F-IVTIME, invalid time." I have narrowed it down to a specific day in the history file. CMS/VERIFY/REPAIR did not fix it, nor did ANALYZE/DISK/REPAIR. How can I fix the bad history record or remove it? OpenVMS V6.1, DEC/CMS version V3.6-10.
If the verify repair pass doesn't deal with it, the customer support center has tools which manually extract everything and replace it into a new library.
Or you can patch the data that CMS doesn't like. That involves finding the record and sorting out what CMS doesn't like. If it's a binary date, patch it. If it's a text date, you can still patch it.
Or you can blow away all of the history.
CMS is traditionally sensitive to more than a 30 second skew from the current time.
Both CMS V3.6-10 and OpenVMS (VAX and Alpha) V6.1 are over a decade old, and long since unsupported. You might upgrade and see if newer CMS deals with it more to your satisfaction. A bunch of corruptions got fixed in newer releases. (But since you're here, I'm guessing that upgrade is not an option.)
If you can't upgrade, try patch; directly "bomb" library. Or blow away the history and/or start over with a new library. (Do make a copy of the library, and practice on that.)
You are correct about this stuff being old - no support available. We need to keep our history records, however, we can sacrifice some if it will save the rest. Can I delete a single record or day of history?
I'm not familiar with patching. What is the method? Is there a recommended tool?
There's no way to answer your question without poking around to see the details of the particular history file corruption(s) CMS has detected. This could easily be some sort of a block-level disk error underneath the CMS library, or a CMS library corruption.
Patching a CMS library component file is an advanced-level repair technique -- you're literally bombing data bytes within the history file with new values, directly writing to the CMS file and repairing whatever it is that CMS doesn't like about these records. (Or attempting same.)
I've found various corruptions that used to crop up occasionally with V3.5, V3.6 and V3.7 have largely disappeared with more recent releases. There's no chance you can try a CMS upgrade and see if a newer VERIFY/REPAIR will address this case?
It turns out that we will be upgrading over the next year and we will test the VERIFY/REAPIR command. For now, I will live with the bad record in the CMS history file.
