[z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem

Adam Baldwin

[z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem
Can anyone explain the following? I'm sure that I'm missing something obvious but....

Directly after migrating a subsystem from V7 to V8 CM we hit problems with 00C90101 abends.
The problem turned out to be bad data in tablespace header pages.

We ran REPAIR LOCATEs to fix the header pages and the problem was solved.

One week later the subsystem was bounced. On startup the same header page problem in the same tablespaces manifested itselg again.

I'm baffled as to how a STOP / START of DB2 can have caused the repair locate to be undone.

If anyone has the answer....

Cheers, Adam

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Roy Boxwell

Re: [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem
(in response to Adam Baldwin)
3rd party reorg??? I vaguely remember that a 3rd party reorg was using
"reserved" bits and it caused grief in V8...check your reorg jobs to
see....

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Straße 5
40470 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert



Adam Baldwin <[login to unmask email]>
Gesendet von: IDUG DB2-L <[login to unmask email]>
22.11.2010 16:06
Bitte antworten an
IDUG DB2-L <[login to unmask email]>


An
[login to unmask email]
Kopie

Thema
[DB2-L] [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem






Can anyone explain the following? I'm sure that I'm missing something
obvious but....

Directly after migrating a subsystem from V7 to V8 CM we hit problems with
00C90101 abends.
The problem turned out to be bad data in tablespace header pages.

We ran REPAIR LOCATEs to fix the header pages and the problem was solved.

One week later the subsystem was bounced. On startup the same header page
problem in the same tablespaces manifested itselg again.

I'm baffled as to how a STOP / START of DB2 can have caused the repair
locate to be undone.

If anyone has the answer....

Cheers, Adam

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 *
http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it!
*
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Adam Baldwin

Re: [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem
(in response to Roy Boxwell)
Roy - a third party reorg was the cause of the original problem.

What's puzzling me is that having run the repair to fix the reserved bits in the header pages the problem then returned with the next stop / start of DB2.

Problem was "fixed" for an entire week. Stop and Start of DB2 - and bang, problem returned. For some reason, the repair appears never to have been externalized.

Cheers, Adam

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Roy Boxwell

Re: [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem
(in response to Adam Baldwin)
I would then hazard a guess that you repaired the bits in memory but they
were not, for some unknown reason, externalized to disk - I dont believe
this myself but as Sherlock Holmes famously said "when you have eliminated
the impossible, whatever remains, however improbable, must be the truth"

Worst case is - DB2 has the data in memory, you REPAIR the disk version,
DB2 externalizes the memory version - boom! You're back with crud data

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Straße 5
40470 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert



Adam Baldwin <[login to unmask email]>
Gesendet von: IDUG DB2-L <[login to unmask email]>
23.11.2010 08:30
Bitte antworten an
IDUG DB2-L <[login to unmask email]>


An
[login to unmask email]
Kopie

Thema
Re: [DB2-L] [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem






Roy - a third party reorg was the cause of the original problem.

What's puzzling me is that having run the repair to fix the reserved bits
in the header pages the problem then returned with the next stop / start
of DB2.

Problem was "fixed" for an entire week. Stop and Start of DB2 - and bang,
problem returned. For some reason, the repair appears never to have been
externalized.

Cheers, Adam

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2
information. *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's Listserv


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Adam Baldwin

Re: [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem
(in response to Roy Boxwell)
Roy, the "in memory" header page was ok - directly after the repair the objects became accessable. This wouldn't have been the case had the VSAM page been repaired whilst leaving a corrupt copy in memory.

What we have seen points to the header pages having been repaired in memory, remaining there for 6 days without being externalized, and then not being externalized even at STOP DB2.

Watson....the needle....

Cheers, Adam

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv