Rob Wunderlich writes: >JDBC/ODBC access to z/os DB2 works well, but it's expensive >(relative term).
I think you used the word "perceived" elsewhere, and there are those perceptions, yes. It's a multi-party effort to make sure the truth is understood. >The cost for drivers, whether DB2 Connect or another vendor, is enormous. I >have web servers, data warehousing, windows server apps and desktop >clients all accessing DB2 data. If I want to add a CPU to webapp server, the >driver upgrage fee is more than the cost of the entire server. You would seem to be in the perfect situation, at least outwardly, for DB2 Connect Unlimited Edition. It's very much like the MQ Client Access Feature: you pay a fixed rate based on your MSUs, and you're done. You don't even need to contact IBM when you add server #685 or user #3163. (Put Connect on Linux on z and add a zIIP for best results.) Other vendors may offer similar terms. I'm sure all those Web servers, data warehousing servers, and server apps are free to acquire and maintain, but that's a topic for another day. :-) On the general topic, there are about a million ways already to copy DB2 z/OS data somewhere and do something with it. They all share some common disadvantages, many already mentioned. The winds seem to be blowing against doing that sort of thing nowadays. A lot of businesses are terribly worried about failing to protect sensitive data, and the word "copy" is inherently antithetical to data protection (except in the narrow and tightly controlled DR sense). I call the trend "data recentralization." There's also an increasing appreciation for the high costs of too highly distributed data models, and data warehouses are becoming much more mission-critical (and numerous).... Interesting times we live in. My free advice, for what it's worth, is to figure out better ways for customers to take advantage of DB2 (and other data) right on the mainframe, to answer critical business questions on a need-to-know basis, with up-to-the-second consistency. There's a tremendous market for that. IMHO, creating the million-and-first way to copy data somewhere else to then operate on it won't be as interesting. By the way, I expect that going behind DB2's back and accessing underlying files will become increasingly less and less fruitful. DB2 function has been galloping ahead rapidly, and it's going to get more and more difficult to make any sense of what's underneath. There's also no guarantee whatsoever that what's underneath will stay the same from version to version. And more and more of it is going to be encrypted anyway as, for example, customers use SQL ENCRYPT vocabularies, so you'll need the key(s) to decode it. Those who have the key probably won't (shouldn't) give it. There are also complications like stored procedures, which are getting more numerous and complex, expanding data types, XML, rapid changes to indices, conversion to Unicode.... This stuff is in very rapid motion, and you'll need to keep up. Basically what you're talking about is reverse engineering a good chunk of DB2, and to keep reverse engineering it as DB2 evolves. My hunch is that's a big, never-ending project. :-) - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
