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:
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,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notification on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
Improve messaging surrounding the +20272 SQL warning in cases of a -904
A DBA was running an ALTER NOT CLUSTER. The ALTER should have converted the tablespace to table-controlled partitioning, but it encountered a -904. I have copied the output to "additional details".
In the SPUFI output, after the -904, the ALTER displayed DSNT404I with SQLCODE +20272, indicating that the tablespace was converted to Table-Controlled partitioning. However, this conversion was NOT done due to the -904.
We recently opened a ticket to address this. The programmer states that this is "working as designed" and insists that the +20272 was generated BEFORE the -904, despite the output from SPUFI showing it AFTER the -904. (I'm guessing this has to do with the way SPUFI is formatting the information?)
This is confusing, as the output of the +20272 after the -904 seems to suggest that conversion WAS completed, in SPITE of the -904. I think I see what the developer is saying, but I don't believe that +20272 should be set/returned to the user if the conversion fails, as the language/documentation implies a SUCCESSFUL conversion.
I am suggesting that Db2 do one of the following:
Not issue/set +20272 until any units of work that could affect the completion/rollback of the table-controlled partitioning complete successfully.
In the case of a -904 that causes a conversion to fail, provide some notification to the user (possibly in the ADDITIONAL INFORMATION area of the +20272??) that the conversion was rolled back, or replace the +20272 with another warning indicating conversion rollback.
Modify +20272 to indicate that conversion was attempted - the current syntax, "HAS BEEN CONVERTED" implies that the action was completed.
Modify documentation for +20272 to indicate that RESOURCE UNAVAILABLE conditions may cause a conversion to fail, despite the issue of this message/code.
Any of these solutions would likely be sufficient.
Do not place IBM confidential, company confidential, or personal information into any field.