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

Phil Grainger

Re: [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem
(in response to Adam Baldwin)
If what Adam says is true (and I don't doubt that it is), then this could have been caused by the REPAIR utility not setting the updated page bit in the pages changed

This would then fool DB2 into thinking that the pages don't NEED writing out at all (even at shutdown)

Is it possible to check whether the REPAIR syntax you are using is indeed setting the updates page bit(s)??

If so, then I am also stumped

Phil Grainger
Cogito Ltd.
[login to unmask email]
+44 (0) 1298 872 148
+44 (0) 7505 266 768
www.cogito.co.uk

Attend IDUG 2010 - EMEA, the premiere event for DB2 professionals.
8-12 November 2010, Vienna
Learn more at http://www.idug.org/emea


-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Adam Baldwin
Sent: 23 November 2010 07:31
To: [login to unmask email]
Subject: 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

[z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem - elementary, my dear Watson
Hi Roy.

It appears that the problem results from a combination of factors.

After the initial repair of the header page, the repair wasn't consolidated by a recreate of the VSAM. REAIR, COPY, RECOVER TO COPY is the way to go.

In the initial repair, rubbish was removed from offsets 800 - 930. Data was then accessable.
After the STOP / START of DB2, the 00C90101 returned for the same header pages.... but offset 940 was the problem.
A rerun of the original repair - not replacing 940 - "resolved" the problem.
We now will consolidate the repairs so that the vsams get recreated.

All that puzzles me now.... is why offset 940 only became a problem after the STOP / START.

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 Phil Grainger)
I agree!!! Time to migrate to V10 anyway.... ;)

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 14:35
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, 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


_____________________________________________________________________
* 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

Mike Bell

Re: [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem
(in response to Roy Boxwell)
You might want to talk to the nice people at IBM support.

I think I remember a problem I had with REPAIR long time ago.

The combination was REPAIR LOG YES and DB2 START/STOP but the log records
didn't get applied at restart.

Was immediately followed by rerun repair, stop, DSN1PRNT to verify it was
still there, start, image copy, reorg and problem didn't reoccur.

And NO, I didn't get to try to recreate the problem, test my solutions, open
a problem with IBM or anything. Just get production back up.

Mike
HLS Technologies


-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Adam Baldwin
Sent: Tuesday, November 23, 2010 7:36 AM
To: [login to unmask email]
Subject: Re: [DB2-L] [z/OS] DB2 V8 CM - REPAIR LOCATE - strange problem

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

_____________________________________________________________________
* 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