If you go the dbunload route (to tape or disk) I think you need to take the
'serial' option. Sorry, but a little shaky on the exact syntax -- haven't
used it since about 1982.
--------------------------------------------------------
It is possible write your own routine to fix this stuff, if you don't have the
tools others have suggested. Did it once, long ago, back before HP introduced
ILR.
If you feel fancy....
Start by writing a program to read forward along the chain, counting records
read successfully, and remembering the address of the last record read. Then
do another find and read backwards. If you are really lucky, there will be
just one clean break -- you'll reach a point where you have read the exact
number of records that query "form <data-set-name>" says you should have, and
the backward pointer of the record you just read (going backwards) matches the
record number of the last one you read going forwards. At this point, once
you make note of what was in that record, you *might* be able to fix things
with a dbdelet / dbput, but that isn't the way I went, and I don't know if
Image would fix things or just move the break up a notch -- any experts know
what Image would do in that case?
Assuming you didn't fix it above, then enhance your program to write each
record it reads to a disk file. If you want to keep it simple, just skip the
1st step and write a program that does a sequential read thru the whole data
set.
Once that is tested, enhance to delete each record is reads.
Then read the disk file and do dbputs. If the sequence of the records is an
issue, sort to taste first.
----------------------
FWIW, I went the fancy forward/backward route because I was starting from a
pair of programs that would call dbinfo (a lot) copy every record of every set
(except automatic masters) to flat files, and then re-fill the data base after
the appropriate dbutil/dbschema commands rebuild it empty. Sort of a Cobol
version of the ancient Fortran db2disk & disk2db. So I just added a branch
telling it what to do when it hit a bad pointer while reading forward on one
data set.
And if you have such a utility, and a little creativity, it can be really
useful. If your data-bases aren't too huge, and your system has some slack
time overnite or weekends, you can get by for decades without dbunload,
Adager, any other data base tool. 2.6 decades in my case.
----- Original Message -----
From: "Jack Connor" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, April 09, 2008 06:05
Subject: Re: [HP3000-L] BROKEN CHAIN POINTERS
Ditto on the Adager or DBGeneral products; they make life a whole lot
easier.
However, if you have the disc space, you can do a file equate of
DBUNLOAD;DEV=DISC and unload/load from disc.
Also, if you have the RAPID (DICTDBU, etc) you can unload/load single
sets to/from disc.
Jack
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Dave Gale
Sent: Wednesday, April 09, 2008 8:19 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] BROKEN CHAIN POINTERS
Friedrich:
There are 2 options:
1. Use a 3rd party tool like Adager or DBGeneral to do an analysis and
repair.
2. Unload the dataset and reload.
HP never provided any tools with the image database, hence the unload
and load. This is slow and with that type of volume could take days,
depending on your tape technology. I personally prefer Adager as I have
always had good results and excellent support from them.
Hope your day gets better!
Dave
Friedrich Harasleben wrote:
> Dear database experts
>
> we do have a problem on one of our big datasets (>7000000 entries)
>
> FIND risikonummer = "9CW2D5"
> BROKEN CHAIN POINTERS
> 0 ENTRIES QUALIFIED
>
> the problem results in aborting one of our COGBNOS/QDESIGN programs
> with "data access error".
>
> - how can I find out which pointers are broken
> - how can I fix the problem
>
> thanks for any suggestions
> friedrich
>
> Mag. Friedrich Harasleben
> stv. Leiter IT & Operations
>
> Coface Austria Holding AG
> Coface Central Europe Holding AG
> Stubenring 24
> 1010 Wien
> Austria
> T: +43/1/515 54-300
> F: +43/1/515 54-50300
> www.coface.at
> www.cofacecentraleurope.com
>
> Firmenbuchnr. FN 65493 p (Coface Austria) Firmenbuchnr. FN 043204 k
> (Coface Central Europe) Handelsgericht Wien
>
> This e-mail message may contain confidential and/or privileged
> information. If you are not the intended recipient (or have received
> this e-mail in error) please notify the sender immediately and destroy
> this e-mail. Any unauthorized copying, disclosure or distribution of
> the material in this e-mail is strictly forbidden.
>
> P Before printing, please think about the impact it has on the
> environment
>
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
