DB2 for z/OS V8 Adoption

DB2 for z/OS Version 8 has been generally available since March 2004. Of course, there was a big maintenance "patch" that came out in June 2004, so that might be a more "realistic" GA date for this release. But I'll stick with IBM's date of March 2004. So, here it is March 2005, about a year later, and there haven't been a whole lot of shops that have rushed to upgrade to the new version. Why?

First of all, we should take a look at what is there in this latest and greatest version of DB2. Whether you've only seen an overview of DB2 V8, maybe a little more depth on V8, or very detailed V8 coverage, it is obvious that a lot has been changed. And if you've done any reading at all on V8 you can see just how extensive and invasive to the DB2 engine that this version is. Many things had to be "torn up" to add support for features like virtual storage constraint relief, long names, and a Unicode system catalog. This comes with many benefits in terms of performance and new features, but it also means a lot has changed. Indeed, folks at IBM have told us that there are more new lines of code in DB2 V8 than there were total lines of code in DB2 V1. Does anyone out there still dispute that this is a significant release?

So you'll have to do a lot of preparation and learning to migrate and support DB2 V8. Of course, we're used to the work required to migrate to a new version of DB2, but V8 is new. It adds several modes that you'll have to pass through before getting to a full-blown DB2 V8 implementation. The modes are Compatibility Mode (CM), Enabling New Function Mode (ENFM), and New Function Mode (NFM) and only the last one is really and truly V8. DB2 never had "modes" like this in the previous releases; either you were on one verion or the other and there was no grey area. For V8, there are two a grey areas: the light grey of CM and the darker grey of ENFM.

There are several interesting twists to these modes and I will not cover all of them here. Suffice it to say, it can be confusing to figure out whether you can back out to a previous mode or release from whatever current mode you are in. But the more interesting twist is the benefits that accrue from simply going to CM and staying there for awhile. I've spoken to a bunch of DB2 users who are planning on doing just that. The reason is that CM brings with it one of the most important new features of V8 - virtual storage constraint relief (VSCR). With VSCR DB2 has access to boatloads of memory and for sites that are bumping up against the limitations of DB2 V7, VSCR is a godsend. Additionally, CM brings some optimizer improvements, but no other new V8 features are available. So, you can go to CM, get VSCR and optimization improvements, without having to worry about the adoption of new V8 features (training, bugs, etc.) - and you can go back to V7 if need be. Many sites are not clamoring for the other V8 features so the thinking goes - "I'll go to CM and buy some more time before having to worry about this big, hulking new version."

Well, this is all well and good, and if I were a DBA at a major corporation I might just consider doing the same thing. The problem that seems to be cropping up is that CM is "no man's land" in terms of support. It isn't V7 and it isn't V8 and IBM doesn't want to spend a lot of time working on fixing problems in what IBM considers a throw-away piece of code. I mean, it is not like CM will necessarily be there in any future new version - at least not this one. So if you are thinking about staying in CM for a long time, consider coming up with a plan if IBM support is less than forthcoming when they find out you are "living" in CM. You might have to fall back -- or move ahead before you want to do so.

The question everyone is asking themselves is "are the new features really worth it?" And there are a lot of stories flying around "out there" about V8. Roger Miller provides IBM's take on the matter here - and Roger always discusses the issues in a reasonable and knowledgeable manner.

Let's think about some of the more enticing features, though. Yes, everyone can understand the benefits of something like online schema changes. It sounds nice, but then, the devil is in the details, isn't it? Many online schema changes require DB2 to create versions of database objects - one version like the current definition and a new version with the change. Those changes are not made immediately to the data. DB2 will keep track of the versions and convert the data from the old to the new - that is, until you run a REORG. Of course, it can be an online reorganization, but you aren't going to necessarily want to REORG (even online) after every change. So, from the time of the change until the REORG is run any queries accessing changed data will slow down (as DB2 converts from the old format to the new). Now I'm sure online schema changes will evolve and improve over the course of the next few releases of DB2, but this is what we have today. And maybe it isn't worth rushing to V8 to get this.

Likewise with data-partitioned secondary indexes (DPSIs). At first blush it sounds great to be able to partition every index on the same "key" as the table space. Then we can finally administer a single partition without impacting any other partitions. But as you investigate DPSIs you learn that they might not be as efficient as non-partitioned indexes. So, once again, maybe we don't have to rush to V8.

Now I don't want to sound like a nay-sayer. DB2 V8 has a lot of great stuff in it. But maybe, just maybe, most folks aren't yet ready for all that great stuff. In fact, many sites still haven't taken advantage of the great features added to DB2 in V5, V6, and V7. Do you use distinct types? triggers? user-defined functions? How about all of the SQL improvements? How many developers at your shop have even heard about scrollable cursors, let alone used them? Do your developers know how to code CASE expressions - and I don't just mean those simple ones in the DB2 manuals? (Watch Sheryl Larsen present on complex SQL if you want to get some great ideas about the power of CASE expressions.) What about nested table expressions (aka inline views)? Sheryl is great at explaining how to exploit  those, too.

The rapid versioning of system software has caused DBAs and systems programmers to get worn out just trying to keep up with new versions. It isn't just DB2, but every other piece of systems software, too - on PCs, mainframes, Unix boxes, and so on. Every 18 to 24 months, there is a new version that has to be purchased, installed, tested, with users trained, followed by migration to production. Whew! I get tired just thinking about it.

So fewer folks are on the cutting edge (Gartner would call them Type A enterprises). More organizations are using caution and waiting for others to work out the bugs in new versions. Instead of migrating to a new version immediately, even organizations that used to be aggressive are waiting longer. The fly in the ointment here is that it pushes out the quality cycle for a new version. I mean, if fewer "Type A organizations" then there are fewer enterprises shaking out the problems and a new version of software may have more problems for longer periods of time than it may have had in the past. I'm not saying this is the case with DB2 V8 necessarily, just that it seems to be the pervasive trend in the industry. So those "Type C" enterprises will wait even longer - because the Type A and B folks waited. But the software vendors keep on rolling out new versions every year and a half to two years. Sooner or later, something's gotta give.

What do you think? When are you going to migrate to DB2 V8 on z/OS? And how long are you going to stay in compatibility mode? Post your feedback to this blog right here so we all can take a look at your comments, ideas, and thoughts on these matters...