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
