IBM Data and AI Ideas Portal for Customers


This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:


Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,


Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at https://ideas.ibm.com


Add a new idea Subscribe
Status Functionality already exists
Workspace Db2 for z/OS
Created by Guest
Created on Mar 22, 2019

RELATED IDEAS

Merged idea
This idea has been merged into another idea. To comment or vote on this idea, please visit DB24ZOS-I-912 REPAIR CATALOG TABLESPACE command for xml table space.

REPAIR CATALOG TABLESPACE command for xml table space RFE 130710 Merged

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=130710

We are working with OBJECT_CREATE_FORMAT=EXTENDED and with UTILITY_OBJECT_CONVERSION=NOBASIC for a long time without any problem.

In the last time we began to work with these parameters in other DB2's that include many tables with XML columns. The REORG of the entire auxiliary tablespace(as it must done) increase the length of START_TS and END_TS columns in the xml table. We understand it done because of the extend of the RBA. The REORG also upgrade the CURRENT_VERSION of the xml auxiliary tablespace. We believe it done because of the increase of the length of START_TS and END_TS columns.

Until here, there isn't any problem for us.

We are using utilities "like" DSN1COPY for copy the tables including the xml tables. We know how to deal with the DOCID and SYSXMLRELS table. When we try to copy base table with xml column and it's corresponding xml table from source db2 to target db2, we have problem when there is difference between the CURRENT_VERSION of the xml auxiliary tablespace. in regular tables, we are using REPAIR CATALOG TABLESPACE command, but for xml auxiliary tablespace, we get message DSNU068I. This situation can happen when the table in the source was created with OBJECT_CREATE_FORMAT=EXTENDED and the table in the target was created with OBJECT_CREATE_FORMAT=BASIC and was converted to EXTNDED RBA by REORG. Of course, the opposite situation is also problematic.

The solution of create the tables with BASIC and the convert them to extended is not applicable for us, because we always create new xml tables and want to copy form an old xml table with CURRENT_VERSION=1 and the changes of OBJECT_CREATE_FORMAT from EXTENDED to BASIC all the time is not good and risky.

The option to use UNLOAD/LOAD is not a good solution also because o:

1) We copy tha data many time per a month.

2) We have many xml tables.

3)In general, the width of xml is big, so unload load take a lot of time.

So, as we understand the options, the only good solution is to allow REPAIR CATALOG TABLESPACE command for xml auxiliary tablespace.

use Case:

We are working with OBJECT_CREATE_FORMAT=EXTENDED and with UTILITY_OBJECT_CONVERSION=NOBASIC for a long time without any problem.<br/><br/>In the last time we began to work with these parameters in other DB2's that include many tables with XML columns. The REORG of the entire auxiliary tablespace(as it must done) increase the length of START_TS and END_TS columns in the xml table. We understand it done because of the extend of the RBA. The REORG also upgrade the CURRENT_VERSION of the xml auxiliary tablespace. We believe it done because of the increase of the length of START_TS and END_TS columns.<br/><br/>Until here, there isn't any problem for us.<br/><br/>We are using utilities &quot;like&quot; DSN1COPY for copy the tables including the xml tables. We know how to deal with the DOCID and SYSXMLRELS table. When we try to copy base table with xml column and it's corresponding xml table from source db2 to target db2, we have problem when there is difference between the CURRENT_VERSION of the xml auxiliary tablespace. in regular tables, we are using REPAIR CATALOG TABLESPACE command, but for xml auxiliary tablespace, we get message DSNU068I. This situation can happen when the table in the source was created with OBJECT_CREATE_FORMAT=EXTENDED and the table in the target was created with OBJECT_CREATE_FORMAT=BASIC and was converted to EXTNDED RBA by REORG. Of course, the opposite situation is also problematic.<br/><br/>The solution of create the tables with BASIC and the convert them to extended is not applicable for us, because we always create new xml tables and want to copy form an old xml table with CURRENT_VERSION=1 and the changes of OBJECT_CREATE_FORMAT from EXTENDED to BASIC all the time is not good and risky.<br/><br/>The option to use UNLOAD/LOAD is not a good solution also because o:<br/><br/>1) We copy tha data many time per a month.<br/><br/>2) We have many xml tables.<br/><br/>3)In general, the width of xml is big, so unload load take a lot of time.<br/><br/>So, as we understand the options, the only good solution is to allow REPAIR CATALOG TABLESPACE command for xml auxiliary tablespace.

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.