More on IBM’s RFE Program for Db2 on LUW

Once IBM made the Request For Enhancement (RFE) program workable last year, I blogged about it and tweeted about it, but now that we’ve seen more action on it, I thought I’d share some additional details.

What is an RFE?

First off, an RFE is a request for some feature or functionality in Db2 that does not exist today. If you have ever opened a PMR, only to get a response that boils down to “Working as Designed”, this is your path for addressing that. This is a way of telling IBM how to make Db2 work better for you in very specific ways.

IBM has committed to actually looking at these. We’re not necessarily talking the kind of time frame we may be used to in today’s connected world, but IBM intends to have someone look at an RFE within five weeks of creation or less.

Our votes are also making a difference. You’ll see that several of the items in the top few in terms of votes are already delivered or being worked into the delivery schedule.

Top RFEs

This is how to look at the top few requests by number of votes:
First, go to https://www.ibm.com/developerworks/rfe.
Next, select “Analytics Platform” and then “Db2 for LUW Server” and click the Arrow:

Both “Top” and “New” are interesting ones to look at. You can also set up notifications to get emails whenever a new RFE is opened. One of the things I get out of notifications on new RFEs is that I often learn details about areas that I don’t work with much. For example, I learned that online reorg doesn’t work with expression-based indexes!

RFE Status

Each RFE has a status that IBM defines. Here are the statuses with the way IBM defines them and some notes of my own:

Submitted – The request submitter will automatically be notified by email when the request has been submitted. IBM has not yet evaluated this request and plans to provide an update within 30 days of submission.
Under Consideration – IBM is evaluating this request. A decision or request for more information will be provided within 90 days.
Planned for Future Release – This request is a candidate for a future generally available (GA) release. This generally means that either someone at IBM is already working on the issue, or will soon be working on the issue. IBM intends to deliver on it within the next 6-18 months. IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. IBM will update this request to reflect any changes.
Delivered – This request has been delivered into a previously released version of the product, or imminently in the next available release.
Uncommitted Candidate – This request may not be delivered within the release currently under development, but the theme is aligned with the current multi-year strategy. Basically, this means that the issue is something IBM very much wants to add to the product, but they’re not quite sure when it will be put on the future roadmap. An RFE in this status is not being actively worked on by IBM at the moment. IBM may consider and evaluate any RFE Community feedback for this request through activities such as voting. This status is the one where our votes likely make the largest difference! IBM will update this request in the future.
Declined – IBM has evaluated the request, and has determined that it can not be implemented at this time or does not align with the current multi-year strategy. This request may be resubmitted for consideration after 12 months from the date of decline. The request submitter will automatically be notified by email when the request qualifies for reconsideration and re-submission.
Need More Information– The request submitter will automatically be notified by email when the request requires additional information. IBM is requesting more information from the submitter before the evaluation of the request can be completed. This request will remain open in this status for 30 days, but if the submitter doesn’t respond, the request may be closed with status of ‘Information Not Provided’ (see definition).
Information Provided – The submitter has provided additional information, to assist IBM in evaluating the request.
Information Not Provided – IBM had previously requested more clarifying information. Because the additional information was not provided within 30 days, the request has been closed.
Is a Defect – IBM has identified this as a defect requiring a code change to resolve. Please contact the appropriate customer support team to report this problem. The request has been closed.
Duplicate – IBM has identified the request as a duplicate of another request already posted to this community. Please refer to the linked “duplicate of” request record for information on this request.

Votes matter to set IBM’s priorities on anything in Submitted, Under Consideration, Uncommitted Candidate, and maybe in edge cases, the Planned for Future Release statuses.

Delivered RFEs

Searching on Db2 RFEs that have been delivered currently gives 79 results. The majority of these seem to be ones that were submitted and the submitter did not understand the functionality already exists. The IBM developers added a lot of detail. The one with the highest number of votes was a PDF version of the 11.1 documentation, which IBM delivered about a month ago for most manuals. If you have a specific manual that was not delivered that you want to see, IBM would love to get an RFE for it so they know where to focus next in that area.

One of the early ones they delivered on was un-deprecation of db2_install. It seems that db2_install invokes db2setup, but it still works as it always has, and is beloved by DBAs everywhere for pure simplicity!

My Favorite RFE

My favorite RFE, which I advocate for whenever anyone will listen, is about converting from non-reclaimable table spaces to reclaimable. Go to that link and vote! This is still an issue that my clients spend hundreds of hours a year on. Maybe I should be happy about that as a consultant, but it seems like something that could be vastly simplified. I know there are a lot of complexities, but even an offline utility would be preferable to enduring all the problems with admin_move_table across hundreds or thousands of tables.

Other RFEs I have Opened

There’s a point I get to, usually late at night, when I find myself pulling my hair out at some relatively minor way that Db2 doesn’t quite do things they way I would like it to. Here are a few that I have opened for such issues:

Search Before Opening

Many RFEs are opened only to be closed as already in the product. For me, I’ve usually spent hours working with, experimenting with, and researching an issue before I open an RFE. I often also talk to other Db2 DBAs about an issue before I get to the point of opening an RFE. I strongly suggest you really spend time on an issue before going the RFE route.

Before opening an RFE, look to see if there is already an RFE open for what you want. Your time is much more efficiently spent publicizing the RFE and getting others to vote on it than on creating a duplicate. IBM’s time is much more efficiently spent addressing the existing RFE than looking at and closing a duplicate. A search like this can also help you avoid false duplicates – if you incorrectly name your RFE very similarly to an existing RFE when it is very different, it may be incorrectly closed as a duplicate.

Providing information

Give as many details as possible when describing the issue and the desired solution. Offer parameters of a solution that would work and any solutions that would not work. Describe the issue more than one way. The more information you give, the more likely IBM is to be able to directly move it into an active status of some sort. If you do not provide enough information, IBM will contact you and if you don’t respond in a timely manner, they may close the RFE with a status of “Information not Provided”

I like to try to describe the problem I’m trying to solve and the parameters of the solution I would like to see. There are a vast number of ways that some RFEs could be delivered. For example, my RFE on session-level reset for monitoring through MON_GET* could easily be delivered by making system objects out of the stored procedures and table functions from a developerWorks article on emulating monitor reset. Or it could be incorporated into the engine more directly. I’d even be happy with a whole duplicate set of MON_GET* delta tables. There are a ton of different ways it could be done and satisfy the basic requirement. By the way, that one is in an Uncommitted Candidate status (the one where votes are most likely to make a difference) – if you like the idea, please go vote for it!

I also like to describe any known workarounds for an issue and why they don’t work for me.

If your request is much more specific, like Make SYSMON_GROUP configurable online, there are fewer parameters to give around the solution, but you should still describe the reason you need this to give IBM context and allow them to suggest alternate solutions.

Continual Improvement

This is an area that is really driven by community involvement. When the community became aware that this process existed, we pushed IBM until it finally became actually workable. I brought it up in nearly every panel discussion, Technical Advisory Board, and every interaction with IBMers who might be involved that I could for a couple of conferences. I talked about it with others, and they pushed for it in similar interactions. Without the community pushing, it likely would have continued to languish. IBM wants to improve the process. This includes both internally and the user experience with the process. If you have any frustrations with the process, let me know in the comments below, and I will do my best to make sure IBM sees them.