00C90207

Ruediger Kurtz

00C90207
--
HUK-COBURG
Versicherungen - Bausparen
Abteilung Informatik
Bahnhofsplatz
96450 Coburg
Tel. 09561/96-3914
Fax. 09561/96-3678
mailto:[login to unmask email]
Attachments

  • import1 (2.6k)
  • import2 (1.7k)

Michael Ebert

Re: 00C90207
(in response to Ruediger Kurtz)
Hello,

this sounds like a problem we had a while ago. It was caused by an update to a
partitioning key that caused the record to move to a different partition. In our
case, if I remember correctly, a QMF query worked but SPUFI did not. I guess
this is caused by indexed vs. TS Scan access.
If this is indeed the same as your problem, there's a PTF for it. I searched my
emails, but unfortunately I did not find anything relating to this problem so
you have to look in IBMLINK for the PTF Number.

Good luck

Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany

PS. Did you notice - the email below again had the "Please respond to <sending
person>" instead of "Please respond to DB2 Data Base Discussion List"... how
come?




From: Ruediger Kurtz <[login to unmask email]> on 16/12/99 14:58 GMT



Please respond to [login to unmask email]


To: [login to unmask email]


cc: (bcc: Michael Ebert/MUC/AMADEUS)




Subject: 00C90207




--
HUK-COBURG
Versicherungen - Bausparen
Abteilung Informatik
Bahnhofsplatz
96450 Coburg
Tel. 09561/96-3914
Fax. 09561/96-3678
mailto:[login to unmask email]


Message-ID: <[login to unmask email]>
Date: Thu, 16 Dec 1999 15:43:23 +0100
From: Ruediger Kurtz <[login to unmask email]>
Reply-To: [login to unmask email]
Organization: HUK-COBURG
X-Mailer: Mozilla 4.04 [de] (OS/2; I)
MIME-Version: 1.0
To: [login to unmask email]
Subject: [Fwd: 00C90207]
Content-Type: multipart/mixed; boundary="------------7E6640114DC9F045816A4EB5"



Sorry if this gets out twice but I received some error-messages;



--
HUK-COBURG
Versicherungen - Bausparen
Abteilung Informatik
Bahnhofsplatz
96450 Coburg
Tel. 09561/96-3914
Fax. 09561/96-3678
mailto:[login to unmask email]


Message-ID: <[login to unmask email]>
Date: Thu, 16 Dec 1999 15:03:55 +0100
From: Ruediger Kurtz <[login to unmask email]>
Reply-To: [login to unmask email]
Organization: HUK-COBURG
X-Mailer: Mozilla 4.04 [de] (OS/2; I)
MIME-Version: 1.0
To: [login to unmask email]
Subject: 00C90207
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi friends, Romans, countrymen out there,

today I got a call from one of our application designers who was running
a query in our test subsystem. He tried the query as a SPUFI-member as
well as a batch-job; either way the query abended with the reason-code
00C90207 (a pointer pointing to a wrong overflow-record); he then
modified the query leaving out a 'where-condition' and lo and behold,
the query ended successfully; after consulting our system-programmers we
ran recovery on that tablespace but to no avail; CHECK DATA gave us
clues as to which partition might be in error, but not to which page.
Eventually, we resorted to running REORG on the tablespace and this did
the job.
Now we are wondering as to what might have caused that particular
problem and why leaving out a where-condition caused the job to end
successfully.

Any comments and any suggestions welcome.

Here's the query:

Select 1 from table a
where a.col < number
and exists
(select 1 from table b
where a.col = b.col
and b.col1 > date
and b.col2 = 'ABCD');

This query abended either way, leaving out the 'where a.col < number'
caused the query to end successfully. We ran REORG on the tablespace of
table a.

TIA Ruediger Kurtz





--
HUK-COBURG
Versicherungen - Bausparen
Abteilung Informatik
Bahnhofsplatz
96450 Coburg
Tel. 09561/96-3914
Fax. 09561/96-3678
mailto:[login to unmask email]