Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Chris Muncan

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Hi all.  Looking for some assistance here.  I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards.  For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING

 

For the whole process, this is what we are doing:

  1. recreate the target tablespace
  2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
  3. ensure that the tablespace is in fact empty
  4. DB2 -STOP target tablespace
  5. DSN1COPY - FULLCOPY
  6. DSN1COPY - INCRCOPY
  7. repeat #6 for all INCRCOPY to recovery point in time
  8. DB2 -START target tablespace
  9. RUNSTATS
  10. perform some SQL updates
  11. REBUILD INDEX
  12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.

 

Any help on this would be greatly appreciated.

Also, we are on V12R1M100

 

Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]

Chris Hoelscher

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Chris Muncan)
I aint no expert, but:

Explanation
The table schema definition in the system page or the table version number
does not match the information in the DB2 catalog table for the same object.

This problem usually occurs after DSN1COPY is used to copy data.

System action
DB2 returns SQLCODE -904. You cannot access the data.

User response
Find the DSN1COPY job that might have caused this error, and use it to
identify the source subsystem. Ensure that the table schema definition that
is defined in the DB2 catalog on the source subsystem matches the definition
on the target subsystem. Correct any inconsistent schemas, and rerun
DSN1COPY. In some cases, the REPAIR CATALOG utility can be run to correct
most version number inconsistencies.


Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266

From: Chris Muncan <[login to unmask email]>
Sent: Saturday, December 8, 2018 10:11 AM
To: [login to unmask email]
Subject: [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')


Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING



For the whole process, this is what we are doing:
1. recreate the target tablespace
2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
3. ensure that the tablespace is in fact empty
4. DB2 -STOP target tablespace
5. DSN1COPY - FULLCOPY
6. DSN1COPY - INCRCOPY
7. repeat #6 for all INCRCOPY to recovery point in time
8. DB2 -START target tablespace
9. RUNSTATS
10. perform some SQL updates
11. REBUILD INDEX
12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.



Any help on this would be greatly appreciated.

Also, we are on V12R1M100



Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]<mailto:[login to unmask email]>

-----End Original Message-----

The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and
do not discriminate on the basis of race, color, national origin, age, disability, sex,
sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national origin, age,
disability, sex, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services, free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.

Philip Sevetson

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Chris Muncan)
You’re brave. I’ve never attempted to apply an incremental copy as (or over) a full copy with DSN1COPY.

Did you run your DSN1COPY jobs with OBIDXLAT specifying all object identifier (DBID, OBID, PSID) mappings from the source to the target environment? Without this, I don’t see how you could be getting good results from this process. (Also, how do you run DSN1COPY on an incremental copy dataset??)

--Phil Sevetson

From: Chris Muncan [mailto:[login to unmask email]
Sent: Saturday, December 08, 2018 10:11 AM
To: [login to unmask email]
Subject: [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')


Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING



For the whole process, this is what we are doing:

1. recreate the target tablespace
2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
3. ensure that the tablespace is in fact empty
4. DB2 -STOP target tablespace
5. DSN1COPY - FULLCOPY
6. DSN1COPY - INCRCOPY
7. repeat #6 for all INCRCOPY to recovery point in time
8. DB2 -START target tablespace
9. RUNSTATS
10. perform some SQL updates
11. REBUILD INDEX
12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.



Any help on this would be greatly appreciated.

Also, we are on V12R1M100



Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]<mailto:[login to unmask email]>

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Carol Anne Sutfin

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Philip Sevetson)
You may need to Rebuild the Indexes before you try RUNSTATs.  
Check the status of the table space and indexes after the last DSN1COPY for the incremental.
Carol


Sent from my Samsung Galaxy , an AT&T LTE smartphone
-------- Original message --------From: "Sevetson, Phil" <[login to unmask email]> Date: 12/8/18 17:07 (GMT-06:00) To: "'[login to unmask email]'" <[login to unmask email]> Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')


You’re brave. I’ve never attempted to apply an incremental copy as (or over) a full copy with DSN1COPY. 

 
Did you run your DSN1COPY jobs with OBIDXLAT specifying all object identifier (DBID, OBID, PSID) mappings from the source to the target environment?  Without
this, I don’t see how you could be getting good results from this process.  (Also, how do you run DSN1COPY on an incremental copy dataset??)
 
--Phil Sevetson
 
From: Chris Muncan [mailto:[login to unmask email]


Sent: Saturday, December 08, 2018 10:11 AM

To: [login to unmask email]

Subject: [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
 
Hi all.  Looking for some assistance here.  I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards.  For >95% of the tables everything is exactly as expected but for that
remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:
DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)


DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS


PROCESSING
 
For the whole process, this is what we are doing:


recreate the target tablespace
update SYSXLAT control card for the appropriate DBID, PSID, DBID
ensure that the tablespace is in fact empty
DB2 -STOP target tablespace
DSN1COPY - FULLCOPY
DSN1COPY - INCRCOPY
repeat #6 for all INCRCOPY to recovery point in time
DB2 -START target tablespace
RUNSTATS
perform some SQL updates
REBUILD INDEX
FIC
the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.
 
Any help on this would be greatly appreciated.
Also, we are on V12R1M100
 
Much appreciated,
Chris Muncan

Senior Database Administrator - Db2 z/OS

[login to unmask email]
 

-----End Original Message-----


**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate,
copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Site Links:
View post online  
View mailing list online  
Start new thread via email  
Unsubscribe from this mailing list  
Manage your subscription  


This email has been sent to: [login to unmask email]

ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.

BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.

http://www.ESAIGroup.com/idug



Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2

Paul Ogborne

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Philip Sevetson)
Hi,
Would merging the full and incremental copies first, simplify?
Regards,
Paul.

> On 8 Dec 2018, at 23:07, Sevetson, Phil <[login to unmask email]> wrote:
>
> You’re brave. I’ve never attempted to apply an incremental copy as (or over) a full copy with DSN1COPY.
>
> Did you run your DSN1COPY jobs with OBIDXLAT specifying all object identifier (DBID, OBID, PSID) mappings from the source to the target environment? Without this, I don’t see how you could be getting good results from this process. (Also, how do you run DSN1COPY on an incremental copy dataset??)
>
> --Phil Sevetson
>
> From: Chris Muncan [mailto:[login to unmask email]
> Sent: Saturday, December 08, 2018 10:11 AM
> To: [login to unmask email]
> Subject: [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
>
> Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:
>
> DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
> DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
> PROCESSING
>
>
>
> For the whole process, this is what we are doing:
>
> recreate the target tablespace
> update SYSXLAT control card for the appropriate DBID, PSID, DBID
> ensure that the tablespace is in fact empty
> DB2 -STOP target tablespace
> DSN1COPY - FULLCOPY
> DSN1COPY - INCRCOPY
> repeat #6 for all INCRCOPY to recovery point in time
> DB2 -START target tablespace
> RUNSTATS
> perform some SQL updates
> REBUILD INDEX
> FIC
> the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.
>
>
>
> Any help on this would be greatly appreciated.
>
> Also, we are on V12R1M100
>
>
>
> Much appreciated,
>
> Chris Muncan
> Senior Database Administrator - Db2 z/OS
> [login to unmask email]
>
>
> -----End Original Message-----
> **This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ESAi has well-regarded tools for Fast Cloning, Buffer Pool Tuning, Log Analysis, TDM & more.
> BCV4, BCV5, BPA4DB2, ULT4DB2... modern power tools to get the job done faster & easier than ever.
> http://www.ESAIGroup.com/idug
>
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>

Chris Muncan

RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Philip Sevetson)

Yes the XLAT control card is setup correctly. We’ve checked this many times and have now automated this process to avoid human error. So the OBID PSID DBID are all correct.

again I ran my process for over 100 tables yesterday and they were all successful, well almost all with the exception of these tables...so I know it is a process that works MOST of the time.

 

reason why I am running runstats on the table data before rebuild index is I needed to get the columns updated of systablepart so that the index rebuild knows how many records to expect in the sort.

 

I could try to fudge the numbers first in the RTS with what is currently in our source table then try the rebuild index before runstats.

 

DSN1COPY has a nifty option for the type of file that is being used as input: FULLCOPY, INLCOPY, INCRCOPY, etc. So what we are doing is using either a FULLCOPY or INLCOPY as our starting point on an empty table then using DSN1COPY again to apply the INCLCOPY which has all of the pages updated since last full copy.

 

Again, I’m just not sure why this is happening to these few tables where as the vast majority using the exact same process works just fine.

 

Worst case scenario is we end up using the REPAIR utility?

 

Any additional input or thoughts are welcomed!

 

 

Chris Muncan

Senior Database Administrator - Db2 z/OS

[login to unmask email]

Chris Muncan

RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Chris Muncan)

Alright so managed to get this working now.  Not exactly sure why, but I had to run REPAIR CATALOG TABLESPACE DB.TS TEST to confirm, then without the "TEST" to fix the catalog.  But the output from the TEST showed that the table version in the catalog doesn't match the page set.  Very bizarre but after running the REPAIR CATALOG TABLESPACE DB.TS, it fixed it and we are rocking and rolling along now!

 

DSNU000I 342 21:40:55.04 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = R1396C00
DSNU1044I 342 21:40:55.05 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
DSNU050I 342 21:40:55.06 DSNUGUTC - REPAIR
DSNU650I + 342 21:40:55.08 DSNUCBVR - CATALOG TABLESPACE DB.TS TEST
DSNU675I + 342 21:40:55.17 DSNUCBVR - HIGH VERSION FOR DBID=X'0181' PSID=X'0319' IN THE
DB2 CATALOG IS 0, BUT IN THE PAGE SET IS 1.
DSNU671I + 342 21:40:55.18 DSNUCBVR - DBID=X'0181' PSID=X'0319' OBID=X'0922'
TABLE VERSION IN THE CATALOG DOES NOT MATCH THE PAGE SET.
DSNU381I + 342 21:40:55.19 DSNUGSRX - TABLESPACE DB.TS IS IN COPY PENDING
DSNU010I 342 21:40:55.21 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4

 

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]

J&#248;rn Thyssen

RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Chris Muncan)

Hi Chris,

The tables that fail are those that have been altered. I think there are several ways to fix this:

1) Replay the DDL on the target: instead of CREATE TABLE with 10 columns do CREATE original table with 8 columns + 2x ALTER TABLE ADD COLUMN ... [I have tested this]

2) REORG full table space before COPY and DSN1COPY. This ensures that all rows have been materialised to latest table version. Then do the REPAIR and hopefully you’re good [untested from my side]

3) UNLOAD/LOAD the affected tables [I have tested this]

 

There is a reason why there exists vendor products like IBM Db2 Cloning Tool. We have a lot of logic implemented to handle table versioning differences... :)

 

Best regards,

Jørn Thyssen

Rocket Software
77 Fourth Avenue • Waltham, MA • 02451 • USA
E: [login to unmask email] • W: www.rocketsoftware.com 

2018 IBM Champion.

Views are personal. 

Larry Jardine

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Chris Muncan)
Are you sure you are getting the data you want at the target?

I don't think DSN1COPY is applying changes for the incremental copies; it is overlaying the vsam files with JUST the incremental copy data. DSN1COPY is external to DB2, so I don't think it could know what to do with incremental changes.

As someone else suggested, you may want to merge the full with the incrementals first, then run one DSN1COPY.

Larry Jardine
Database Advisor, CVS Health

From: Chris Muncan <[login to unmask email]>
Sent: Saturday, December 8, 2018 10:11 AM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****

Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING



For the whole process, this is what we are doing:

1. recreate the target tablespace
2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
3. ensure that the tablespace is in fact empty
4. DB2 -STOP target tablespace
5. DSN1COPY - FULLCOPY
6. DSN1COPY - INCRCOPY
7. repeat #6 for all INCRCOPY to recovery point in time
8. DB2 -START target tablespace
9. RUNSTATS
10. perform some SQL updates
11. REBUILD INDEX
12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.



Any help on this would be greatly appreciated.

Also, we are on V12R1M100



Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]<mailto:[login to unmask email]>

-----End Original Message-----

This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

Phil Grainger

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Larry Jardine)
DSN1COPY will overlay the changed PAGES of an incremental

BUT please make sure NUMPARTS is correct for partitioned objects, otherwise page numbers will be calculated incorrectly
________________________________
From: Jardine, Lawrence J <[login to unmask email]>
Sent: 09 December 2018 21:16:54
To: [login to unmask email]
Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Are you sure you are getting the data you want at the target?

I don't think DSN1COPY is applying changes for the incremental copies; it is overlaying the vsam files with JUST the incremental copy data. DSN1COPY is external to DB2, so I don't think it could know what to do with incremental changes.

As someone else suggested, you may want to merge the full with the incrementals first, then run one DSN1COPY.

Larry Jardine
Database Advisor, CVS Health

From: Chris Muncan <[login to unmask email]>
Sent: Saturday, December 8, 2018 10:11 AM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****

Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING



For the whole process, this is what we are doing:

1. recreate the target tablespace
2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
3. ensure that the tablespace is in fact empty
4. DB2 -STOP target tablespace
5. DSN1COPY - FULLCOPY
6. DSN1COPY - INCRCOPY
7. repeat #6 for all INCRCOPY to recovery point in time
8. DB2 -START target tablespace
9. RUNSTATS
10. perform some SQL updates
11. REBUILD INDEX
12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.



Any help on this would be greatly appreciated.

Also, we are on V12R1M100



Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]<mailto:[login to unmask email]>

-----End Original Message-----
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.

Chris Muncan

RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Phil Grainger)

Yes we found that too in the documentation that if you apply an incremental (INCRCOPY) it will overlay just the changed pages since the last FIC.  We do all of our IICs on the individual part level so it made that part of it very simple.  A bit more work to get done, but simple in the sense we could easily automate the solution for this.

We have just a few tables left now with oddities.  The biggest challenge we have now is we have a non-partitioned table that has multiple datasets allocated but when we define the new target table, it only has 1 dataset and when DSN1COPY attempts to apply the FIC, it complains that it is expecting X datasets but only found 1.  We are still working on getting those corrected, but again only about 10 out of 200+ tables have that specific scenario.

 

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]

Larry Jardine

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Phil Grainger)
Hey, I learned something Another good day.

Larry Jardine
Database Advisor, CVS Health



Proprietary
From: Grainger, Phil <[login to unmask email]>
Sent: Sunday, December 9, 2018 5:00 PM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****
DSN1COPY will overlay the changed PAGES of an incremental

BUT please make sure NUMPARTS is correct for partitioned objects, otherwise page numbers will be calculated incorrectly
________________________________
From: Jardine, Lawrence J <[login to unmask email]<mailto:[login to unmask email]>>
Sent: 09 December 2018 21:16:54
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Are you sure you are getting the data you want at the target?

I don't think DSN1COPY is applying changes for the incremental copies; it is overlaying the vsam files with JUST the incremental copy data. DSN1COPY is external to DB2, so I don't think it could know what to do with incremental changes.

As someone else suggested, you may want to merge the full with the incrementals first, then run one DSN1COPY.

Larry Jardine
Database Advisor, CVS Health

From: Chris Muncan <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Saturday, December 8, 2018 10:11 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [EXTERNAL] [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****

Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING



For the whole process, this is what we are doing:

1. recreate the target tablespace
2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
3. ensure that the tablespace is in fact empty
4. DB2 -STOP target tablespace
5. DSN1COPY - FULLCOPY
6. DSN1COPY - INCRCOPY
7. repeat #6 for all INCRCOPY to recovery point in time
8. DB2 -START target tablespace
9. RUNSTATS
10. perform some SQL updates
11. REBUILD INDEX
12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.



Any help on this would be greatly appreciated.

Also, we are on V12R1M100



Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]<mailto:[login to unmask email]>

-----End Original Message-----
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
-----End Original Message-----

This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

Philip Sevetson

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Larry Jardine)
Yeah, that's kind of brain-rattling. In a cool way, mind.

From: Jardine, Lawrence J [mailto:[login to unmask email]
Sent: Monday, December 10, 2018 9:35 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Hey, I learned something Another good day.

Larry Jardine
Database Advisor, CVS Health



Proprietary
From: Grainger, Phil <[login to unmask email]>
Sent: Sunday, December 9, 2018 5:00 PM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****
DSN1COPY will overlay the changed PAGES of an incremental

BUT please make sure NUMPARTS is correct for partitioned objects, otherwise page numbers will be calculated incorrectly
________________________________
From: Jardine, Lawrence J <[login to unmask email]<mailto:[login to unmask email]>>
Sent: 09 December 2018 21:16:54
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Are you sure you are getting the data you want at the target?

I don't think DSN1COPY is applying changes for the incremental copies; it is overlaying the vsam files with JUST the incremental copy data. DSN1COPY is external to DB2, so I don't think it could know what to do with incremental changes.

As someone else suggested, you may want to merge the full with the incrementals first, then run one DSN1COPY.

Larry Jardine
Database Advisor, CVS Health

From: Chris Muncan <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Saturday, December 8, 2018 10:11 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [EXTERNAL] [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****

Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING



For the whole process, this is what we are doing:

1. recreate the target tablespace
2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
3. ensure that the tablespace is in fact empty
4. DB2 -STOP target tablespace
5. DSN1COPY - FULLCOPY
6. DSN1COPY - INCRCOPY
7. repeat #6 for all INCRCOPY to recovery point in time
8. DB2 -START target tablespace
9. RUNSTATS
10. perform some SQL updates
11. REBUILD INDEX
12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.



Any help on this would be greatly appreciated.

Also, we are on V12R1M100



Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]<mailto:[login to unmask email]>

-----End Original Message-----
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
-----End Original Message-----
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Phil Grainger

Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')
(in response to Philip Sevetson)
I only learnt about NUMPARTS when I dsn1copied some data to a tablespace and noticed some SVC99 messages where the utility was allocating datasets OTER than the ones I'd specified!
________________________________

Phil Grainger

Principal Enablement Manager

[login to unmask email]

Direct



+44 (0)118 921 8000

Mobile



+44(0)7808 643 479


E2, Eskdale Road
Winnersh
Berkshire
RG41 5TS


[http://media.cms.bmc.com/images/corp_signature_bmclogo_2014.jpg] http://www.bmc.com

[https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]





From: Sevetson, Phil [mailto:[login to unmask email]
Sent: 10 December 2018 14:40
To: '[login to unmask email]' <[login to unmask email]>
Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Yeah, that's kind of brain-rattling. In a cool way, mind.

From: Jardine, Lawrence J [mailto:[login to unmask email]
Sent: Monday, December 10, 2018 9:35 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Hey, I learned something Another good day.

Larry Jardine
Database Advisor, CVS Health



Proprietary
From: Grainger, Phil <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Sunday, December 9, 2018 5:00 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [EXTERNAL] [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****
DSN1COPY will overlay the changed PAGES of an incremental

BUT please make sure NUMPARTS is correct for partitioned objects, otherwise page numbers will be calculated incorrectly
________________________________
From: Jardine, Lawrence J <[login to unmask email]<mailto:[login to unmask email]>>
Sent: 09 December 2018 21:16:54
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

Are you sure you are getting the data you want at the target?

I don't think DSN1COPY is applying changes for the incremental copies; it is overlaying the vsam files with JUST the incremental copy data. DSN1COPY is external to DB2, so I don't think it could know what to do with incremental changes.

As someone else suggested, you may want to merge the full with the incrementals first, then run one DSN1COPY.

Larry Jardine
Database Advisor, CVS Health

From: Chris Muncan <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Saturday, December 8, 2018 10:11 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [EXTERNAL] [DB2-L] - Runstats failing after DSN1COPY recovery (REASON=X'00C900E3')

**** External Email - Use Caution ****

Hi all. Looking for some assistance here. I'm recovering tables from one database to another and we are using DSN1COPY to load the FIC, then apply the incremental copies afterwards. For >95% of the tables everything is exactly as expected but for that remaining 5%, we have a number of instances that after we apply the FIC+IIC then perform runstats, the runstats fails with:

DSNU050I 342 01:48:27.49 DSNUGUTC - RUNSTATS TABLESPACE DLPZ5.SLP1159 TABLE(ALL) UPDATE(ALL)
DSNU590I + 342 01:48:27.59 DSNUSITS - RESOURCE NOT AVAILABLE, REASON=X'00C900E3', ON DB.TS PROHIBITS
PROCESSING



For the whole process, this is what we are doing:

1. recreate the target tablespace
2. update SYSXLAT control card for the appropriate DBID, PSID, DBID
3. ensure that the tablespace is in fact empty
4. DB2 -STOP target tablespace
5. DSN1COPY - FULLCOPY
6. DSN1COPY - INCRCOPY
7. repeat #6 for all INCRCOPY to recovery point in time
8. DB2 -START target tablespace
9. RUNSTATS
10. perform some SQL updates
11. REBUILD INDEX
12. FIC

the DSN1COPY is completing successfully with no errors or warnings but when runstats runs, we get the resource unavailable but I checked the tablespace and it is in RW and no advisory or restrictive status.



Any help on this would be greatly appreciated.

Also, we are on V12R1M100



Much appreciated,

Chris Muncan
Senior Database Administrator - Db2 z/OS
[login to unmask email]<mailto:[login to unmask email]>

-----End Original Message-----
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
-----End Original Message-----
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image001.jpg (8k)
  • image002.png (9.3k)