Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206

Aurora Emanuela Dellanno

Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206

well, a twist of the tale (going all Genesis on y'all here):

 

let's resume from where we stopped, i.e. we decided to drop and create again all our WRKDB tablespaces, with SECQTY 0, and just leave the last one as SECQTY -1.

 

I made a silly little batch job and ran it against one of our test groups which is at FL100, all good, then ran it against the other group which is at FL500 and I get an abend:

 

***INPUT STATEMENT:
CEE3250C The system or user abend S04E R=00C90206 was issued.
From entry point DSNTEP2 at compile unit offset +000026D2 at entry offset +000026D2 at address 28FB579A. 
DROP TABLESPACE WRKDB31.DSN32K00;

 

I tried it via SPUFI and get exactly the same abend.

 

Furthermore, I have this entry in my SYSLOG:

 

DSNI013I -DB32 DSNIIDIS POTENTIALLY INCONSISTENT 364
DATA
REASON 00C90206
ERQUAL 5002
TYPE 00000302
NAME DSNDB06 .SYSTSTSP.X'0000004F'
CONNECTION-ID=BATCH
CORRELATION-ID=S0100ADT
LUW-ID=DEBWNZ.Q0ADDF32.D816B1EBF7D7=13
DSNI013I -DB32 DSNIIDIS POTENTIALLY INCONSISTENT 365
DATA
REASON 00C90206
ERQUAL 5002
TYPE 00000303
NAME DSNDB06 .STPRTSRI.X'0000000A'
CONNECTION-ID=BATCH
CORRELATION-ID=S0100ADT
LUW-ID=DEBWNZ.Q0ADDF32.D816B1EBF7D7=13

 

please note that the ABEND seems to occur in the other subsystem in our DS group (DB31)...

 

I am opening a PMR as we speak, but I thought I would share the pain and ask for any suggestions...

 

Thanks.

 

Aurora

 

 

 

PS stay safe and healthy

NB black lives matter

Isaac Yassin

Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206
(in response to Aurora Emanuela Dellanno)
Hi Aurora,
Do you happen to have a user index defined on systablespace?
The 1st message says NAME DSNDB06 .SYSTSTSP.X'0000004F'
The 2nd is on an index with non-db2 name : TYPE 00000303 (index)
NAME DSNDB06 .*STPRTSRI*.X'0000000A'
which is inconsistent with the data.


*Isaac Yassin *
*IBM Gold Consultant*
IBM Certified Solution Expert
IBM Certified System Administrator - DB2 for Z/OS 10, 11, 12
IBM Certified Database Administrator - DB2 for Z/OS 9, 10, 11
IBM Certified Database Administrator - DB2 LUW 10.1
IBM Certified Specialist - PureData System for Analytics v7.1
IDUG Israel RUG co-Chair


On Thu, Jun 18, 2020 at 4:11 PM Aurora Emanuela Dellanno <
[login to unmask email]> wrote:

> well, a twist of the tale (going all Genesis on y'all here):
>
>
>
> let's resume from where we stopped, i.e. we decided to drop and create
> again all our WRKDB tablespaces, with SECQTY 0, and just leave the last one
> as SECQTY -1.
>
>
>
> I made a silly little batch job and ran it against one of our test groups
> which is at FL100, all good, then ran it against the other group which is
> at FL500 and I get an abend:
>
>
>
> ***INPUT STATEMENT:
> CEE3250C The system or user abend S04E R=00C90206 was issued.
> From entry point DSNTEP2 at compile unit offset +000026D2 at entry offset
> +000026D2 at address 28FB579A.
> DROP TABLESPACE WRKDB31.DSN32K00;
>
>
>
> I tried it via SPUFI and get exactly the same abend.
>
>
>
> Furthermore, I have this entry in my SYSLOG:
>
>
>
> DSNI013I -DB32 DSNIIDIS POTENTIALLY INCONSISTENT 364
> DATA
> REASON 00C90206
> ERQUAL 5002
> TYPE 00000302
> NAME DSNDB06 .SYSTSTSP.X'0000004F'
> CONNECTION-ID=BATCH
> CORRELATION-ID=S0100ADT
> LUW-ID=DEBWNZ.Q0ADDF32.D816B1EBF7D7=13
> DSNI013I -DB32 DSNIIDIS POTENTIALLY INCONSISTENT 365
> DATA
> REASON 00C90206
> ERQUAL 5002
> TYPE 00000303
> NAME DSNDB06 .STPRTSRI.X'0000000A'
> CONNECTION-ID=BATCH
> CORRELATION-ID=S0100ADT
> LUW-ID=DEBWNZ.Q0ADDF32.D816B1EBF7D7=13
>
>
>
> please note that the ABEND seems to occur in the other subsystem in our DS
> group (DB31)...
>
>
>
> I am opening a PMR as we speak, but I thought I would share the pain and
> ask for any suggestions...
>
>
>
> Thanks.
>
>
>
> Aurora
>
>
>
>
>
>
>
> PS stay safe and healthy
>
> NB black lives matter
>
> -----End Original Message-----
>

Aurora Emanuela Dellanno

RE: Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206
(in response to Isaac Yassin)

Hey Isaac!

 

we have no idea what that index can or could be - it's not a user index...

 

IBM are pointing us to this APAR (brand spanking new) but we have not done any create index: https://www.ibm.com/support/pages/apar/PH17967

 

Meh.

 

Thanks, say hi to Leah!

 

Aurora

 

PS stay safe and healthy

NB black lives matter

Kai Stroh

RE: Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206
(in response to Aurora Emanuela Dellanno)

The error message from Db2 does not leave a lot of room for interpretation. I agree with Isaac, there seems to be a user defined index on the SYSIBM.SYSTABLESPACE table.

Db2 says there is an indexspace DSNDB06.STPRTSRI that is associated with the tablespace DSNDB06.SYSTSTSP and on page X'0000000A' of the index there should be an entry pointing to page X'0000004F' of the tablespace. Db2 probably wants to remove this entry when WRKDB31.DSN32K00 is dropped, but it can't find the index entry and that's a problem.

Have you double checked if the following query returns anything?

 

SELECT CREATOR, NAME,       
TBCREATOR, TBNAME,          
DBID, OBID, ISOBID          
CREATEDBY, CREATEDTS,       
ALTEREDTS                   
FROM SYSIBM.SYSINDEXES      
WHERE DBNAME = 'DSNDB06'    
AND INDEXSPACE = 'STPRTSRI'

 

Thanks

Kai

--
Kai Stroh
UBS Hainer
Fast, efficient Db2 z/OS data migrations and renewals. That’s BCV5.
Learn how the Test Data Management Field Guide can help you to improve your own process.

Isaac Yassin

Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206
(in response to Aurora Emanuela Dellanno)
Hi,
It's not an IBM index (should have a name starting with DSN*).
Maybe something from the past when someone at the site played around with
user defined indexes on the catalog.
I suggest to go over all your catalog indexes to find any other culprits
(hopefully none).
Try to get rid of that index.
I have a system at FL506 and have no problems to "play around" with DSNDB07
datasets (btw - all have 0 secqty).

Isaac

On Thu, Jun 18, 2020 at 5:21 PM Aurora Emanuela Dellanno <
[login to unmask email]> wrote:

> Hey Isaac!
>
>
>
> we have no idea what that index can or could be - it's not a user index...
>
>
>
> IBM are pointing us to this APAR (brand spanking new) but we have not done
> any create index: https://www.ibm.com/support/pages/apar/PH17967
>
>
>
> Meh.
>
>
>
> Thanks, say hi to Leah!
>
>
>
> Aurora
>
>
>
> PS stay safe and healthy
>
> NB black lives matter
>
> -----End Original Message-----
>

Aurora Emanuela Dellanno

RE: Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206
(in response to Isaac Yassin)

Hi all,

 

I did a CHECK INDEX(ALL) TABLESPACE DSNDB06.SYSTSTSP and there is an index defined by IBM Guardium with some broken entries.

 

This is not a new index, by the way. 

 

Anyway, we rebuilt it and the issue now seems fixed, so the new PTF from APAR https://www.ibm.com/support/pages/apar/PH17967 is very much what we need.

 

Thanks all for your input.

 

Aurora

 

PS stay safe and healthy

NB black lives matter

Aurora Emanuela Dellanno

RE: Db2 12 FL500 code level V12R1M506 - DROP TABLESPACE WRKDB31.DSN32K00 abend S04E R=00C90206
(in response to Aurora Emanuela Dellanno)

just a quick update - since the Db2 group on FL500 is a sandbox - cloned from a test group, we ran a check index on the test system, and found literally hundreds of broken pointes for DSNDB06.SYSTSTSP.

 

"funnily" enough, though, the DROP / CREATE had worked perfectly well on that Db2 group, before any repair, a couple of days ago.

 

Bewildered in Bonn, aka Aurora