I agree with you. To develop the support for DB2 queries in PC without accessing the MF is complicate mission.
I will do it only if many people will ask me to do this feature. But I think that the benefit of accessing the DB2 from PC can save a lot of money because it will save the people the money to buy more MF and software and the performance will be the best (the speed of the Intel processor and the hard disk). Thanks, Shai On 1/24/08, Timothy Sipples <[EMAIL PROTECTED]> wrote: > > 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 > ---------------------------------------------------------------------- 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
