> We are revisiting this scenario pretty seriously. I originally posted > this back in April of > this year. Has anyone done this yet? What was the performance like? > David Boyes > responded back then with some very impressive numbers. I'm > wondering if > he would > mind passing along any additional comments?
As you've already found out, Informix on L/390 is really expensive, but switching to UDB may prove complicated for mostly non-technical reasons. DB/2 on IFLs is a real winner for pricing, though (once you actually GET a price). Your biggest obstacles to substituting UDB on Linux for DB/2 on z/OS will be: a) figuring out how to buy it b) working within the technical restrictions c) overcoming your IBM rep's reluctance to losing z/OS MIPS and corresponding revenue. Item C is probably harder than the other two. The technical restrictions are pretty arbitrary for most users (IMHO), and other than needing the DB/2 stub on z/OS to allow batch and CICS to access remote data, there's not a lot that UDB can't do for most organizations (YMMV -- I know there are lots of things in z/OS DB/2 that are Good and Right; there are a lot of cases where it's also overkill). Item A is surprisingly difficult. There are about 12 different ways to buy DB/2 depending on what feature set and sizing you want, and at least my IBM rep had the devil of a time getting a straight answer on what the best pricing would be for this customer. Working through this can take a lot of time. I actually had better luck starting with a pSeries rep -- they seem to have a different path through the IBM SW Group paperwork that actually got me good answers for UDB pricing. DB/2 Connect is still a big question mark, though. > We have done > a 3 year financial plan, and even after investing in the technology, > training etc, it appears to > be a $200,000 savings in that time frame, assuming we can > forestall the > upgrade and the > associated hardware/software upgrade fees. That's pretty consistant with what we're seeing (particularly if you include ISV software upgrade avoidance as one of the factors). Don't forget to include the z/VM and Linux acq and maintenance costs; some folks leave them out, and you do need them for this to be workable. You should also price HA software for L/390 and network HA hardware as part of the mix as well. If you use automated DBMS management tools, check with your vendor on support for L390. At least one vendor has a pretty premium price on the L390 UDB support module compared to the AIX or Solaris ones. > Of course there is a lot of FUD running around with the DBA's > right now > because this is a > new idea for them. Now that we are getting more serious on this idea, > they will be > getting involved, but I want to give them some confidence that this is > being done today and > is a viable situation. In the case I mentioned, it worked out very nicely. End Y1 savings by converting a std engine into an IFL and moving a lot of the workload over to UDB on IFLs netted out at about $310K after we factored in all the additional goodies needed to operate the system (backup, clustering, etc). The end customer seems happy with it. Wrt selling it to the DBAs, try presenting it as a DBMS "utility" -- a network attached database service with them in control of design and operation. They're now the administrators for the enterprise data repository, and they get the flexibility to reconfigure at any point to support new data architectures w/o having to beg for equipment all the time. The idea of putting them in charge of the data on top of the infrastructure you provide was pretty interesting to the customer DBAs in the above scenario; they hadn't considered that a setup like this would make them even more important to the organization, and once they got that point, they rather liked the idea. -- db
