How About Some Respect for DB2 Connect?

Poor DB2 Connect. It's a good piece of code. It really is. It gets SQL requests from off-mainframe requesters (PCs, for example, as well as Linux, UNIX, and Windows-based application servers) to DB2 for z/OS using DB2's Distributed Relational Database Architecture protocol (aka DRDA), and it gets resultant data values and result sets back to the requesters. It supports widely used database interfaces such as Java Database Connectivity (JDBC) and ADO.NET, enabling application programmers to do what comes naturally when it comes to client-side coding. It can make the most of mainframe server resources by pooling and concentrating connections to host DB2 subsystems. It can partner with the Workload Manager (WLM) component of z/OS to effectively balance distributed database requests across multiple DB2 members of a data sharing group on a mainframe parallel sysplex.

This is all good. So, what's the problem? The problem, as I see it, is that too many DB2 Connect-using organizations appear to treat the product as an afterthought with respect to technical support. DB2 Connect often seems to fall between the cracks when it comes to assigning responsibility for availability and performance within a company's IT department. No one seems to want to own this responsibility as it pertains to DB2 Connect. The product is used to route database requests from distributed systems servers to DB2 for z/OS, but the mainframe people say that DB2 Connect support should not be their job because the product doesn't run under z/OS. Likewise, DB2 for Linux, UNIX, and Windows (LUW) people say that DB2 Connect support should not be on their plate because they see it as an extension of the mainframe DB2 system. With people loathe to raise their hands to lead with respect to DB2 Connect support, the role is just assigned to someone who, in the eyes of a senior IT manager, seems to be as good a fit for the job as anyone else. So, who's that guy (or gal)? Ask different organizations, and you'll get different answers. In some cases the lead DB2 Connect person is a DB2 for LUW DBA. In other companies it's a Linux, UNIX, or Windows systems administrator. Sometimes the assignment is given to a network specialist. In any case, when a problem comes up in the distributed DB2 environment, fingers are quick to point to DB2 Connect as the source of the trouble, and the person with DB2 Connect support responsibility is expected to fix things when he or she is not in a good position to do so (at least, not alone) and DB2 Connect might well be a victim of a problem elsewhere in the system, as opposed to being the cause of the problem.

OK, I know that talk is cheap. Enough ranting. How about a solution? Here's my take: some years ago, the wife of an American President (now seeking that job herself) wrote a book, the main theme of which is the idea that "it takes a village" to raise a child (this theme, as I recall, was taken from an African proverb). In other words, the parents of a child have primary responsibility for for the child's upbringing, but others in the community - extended family members, neighbors, friends, teachers, etc. - can and should make important contributions to this very important task. So it should be, I think, with respect to DB2 Connect support. Yes, you need some individual to have primary responsibility and accountability for this job (as a friend of mine likes to say, assigning a task to a committee is a pretty good way of ensuring that the task will not be accomplished), but that person will need, and must have, the support of others with skill sets different from his own. These adjunct members of the DB2 Connect support team need to be aware of and committed to their roles as such, and ready to act with urgency when the DB2 Connect support leader calls on them to help resolve an issue. The leader and his or her associates need to trust each other and rely on each other to get things set right when they go wrong, keeping in mind that DB2 Connect is one component of a distributed database application system that includes DB2 on the mainframe, end-user workstations, and everything in between. It's the holistic approach to DB2 Connect support that will work most effectively.

What would this team look like if I got to choose it's members? Well, in the lead role I'd place a DB2 for LUW DBA. Yes, DB2 Connect is there to route database requests to DB2 on a mainframe, but the product comes out of the same IBM development lab (Toronto) that is home to DB2 for LUW. Furthermore, much of the terminology associated withe DB2 Connect configuration and troubleshooting will be more familiar to a DB2 for LUW DBA than to one of his mainframe DB2 counterparts. That said, a mainframe DB2 DBA and a DB2 for z/OS systems programmer will have to be a part of the support team, because mainframe-side issues can have a significant impact on a DB2 Connect gateway server (examples include the use of DB2 for z/OS block fetch to efficiently send query result sets to requesters, and the possibility that a throughput slowdown on the mainframe could cause distributed requests to back up in a DB2 Connect gateway server). The team should also include an administrator familiar with the operating system under which the DB2 Connect gateway server runs, and a network technician who can quickly get a handle on data transmission situations either upstream or downstream from the DB2 Connect gateway. Additionally, the team should have on it a person or persons familiar with any upstream application servers (e.g., WebSphere, WebLogic, Windows .NET) that send database requests through DB2 Connect.

Oh, and one other thing: this DB2 Connect support team will need to know who to call when questions arise about the application code from which the distributed database requests arise in the first place.

So, that's my opinion on supporting DB2 Connect. It's an important part of your system, and you need to treat it as such. Respect Connect.

Time to Take Another Look at DB2 Data Sharing?

As a member of the DB2 for z/OS National Technical Support Team at the IBM Dallas Systems Center in the 1990s, I had the opportunity to work with some of the first organizations to implement DB2 data sharing on a parallel sysplex. When data sharing was introduced with DB2 for z/OS Version 4, and for some years thereafter, the primary motivation for utilizing the shared-data technology was processing capacity augmentation. IBM had previously shifted from bipolar chip sets to CMOS microprocessors in its mainframe computers, and while this change enabled Big Blue to significantly reduce mainframe TCO, it was some time before the computing power of the CMOS machines matched and then exceeded that of their bipolar predecessors. There were companies in the second half of the 1990s - and even into the 2000s - with DB2-based applications that were pushing the limit of single-system mainframe processing capacity. For these organizations, a shared-disk mainframe cluster (the so-called parallel sysplex) provided the only growth path available. Implementation of DB2 data sharing was an imperative. Some data sharing groups grew to include more than 10 DB2 subsystems.

These days, DB2 data sharing is still of critical importance to many companies, but to a greater and greater extent the key benefit organizations are deriving from the technology is not capacity - it's availability. Oh, sure, data sharing still enables a firm to direct the computing power of multiple mainframe servers at a single DB2 database, but that's not the huge deal it was a few years ago. Because mainframe engines have become so fast (one microprocessor can do today what an entire high-end server did in the 1990s), and because one can get so many engines in one machine (up to 54, whereas 10 used to be considered a lot), numerous companies running parallel sysplexes now could - theoretically, at least - go to from the cluster to a single mainframe and still have room to grow. Would you find many organizations that would seriously consider going from the sysplex to a single-image system? I believe that you wouldn't. People who love their DB2 data sharing groups now do so largely because there's a greater emphasis than ever before on ultra-high availability, and no platform delivers the goods in that department like a parallel sysplex.

DB2 data sharing helps organizations to achieve dial-tone quality by greatly reducing the scope of unplanned outages and very nearly eliminating the need for planned outages. Consider the unplanned outage impact of data sharing. I know of a company that runs a 9-way DB2 data sharing group. Last year, one of the DB2 subsystems in this group abended (in itself, a very rare occurrence). The result? Work continued to flow to the other 8 members of the data sharing group, the failing subsystem was automatically brought back online in less than two minutes, and none of the company's clients noticed an impact from the DB2 failure. In the area of planned outage elimination, data sharing has enabled organizations to apply maintenance to the hardware and software components of a DB2 data sharing group with no need for a maintenance window. How is this done? Simple: a DB2 subsystem is quiesced (in-flight units of work complete, but new requests are routed to other members of the group) and then restarted to activate newly applied software fixes (the same could be done with a z/OS image, or even a mainframe server), and the process is repeated in a round-robin fashion until the maintenance is active on all of the members of the group (DB2 subsystems at a maintenance level "n" can run concurrently with members at an "n + 1" level of maintenance as the round-robin process runs its course). About the only thing requiring a group-wide shutdown (and a relatively brief one, at that) is a switch to a new global locking protocol (I believe that this has happened once since data sharing was introduced) or the running of the CATMAINT job that changes the catalog structure for a new version of DB2 (many companies upgrade their DB2 subsystems to a new version of the code about once every two to three years). DB2 data sharing enables companies to walk the 24x7 walk, versus just talking the talk (I'm originally from Texas, and I actually speak this way sometimes).

Perhaps super-high availability sounds good to you, but you're afraid that data sharing is too expensive for your organization. Think again. It's a good bit less expensive that it was in the early days. For one thing, the advent of internal coupling facilities (CFs provide shared-memory resources which house the global buffer pools and lock structures used by members of the DB2 data sharing group) has taken the hardware cost of data sharing down considerably. On top of that, the CPU cycles spent in the form of data sharing-related overhead has dropped significantly over the years, thanks to faster coupling facility links, faster CF engines, and enhancements in DB2, z/OS, and Coupling Facility Control Code - some organizations drive large data sharing workloads with extensive inter-DB2 read/write concurrent data access, with overhead levels in the high single digits of percent.

So, if you've been thinking that DB2 data sharing is only for companies with gargantuan compute capacity needs and very deep pockets, think again. Data sharing could very well be just the ticket for your organization.

Athens, DB2, and Application Development

I am writing this post in Athens, Greece, where I am participating in the 2007 International DB2 Users Group (IDUG) European Conference. I have been to a number of IDUG conferences over the years, in various parts of the world, but the 2007 Athens event has been, for me, one of the most satisfying. Yes, the venue is great, but my positive experience this week is attributable only in part to a hike up the Acropolis and the wonderful Greek food. What really has me pumped here in Athens is the emphasis - at a DB2-focused conference - on topics pertaining to application development. I have long thought that the real value of data is based on the extent to which it can be transformed into useful information, and applications are typically the means by which this data-to-information transformation takes place.

The application-oriented buzz at this event has me excited for two reasons. First, it is a reflection of the increase in attendance of application developers at IDUG conferences (this accompanied by an increase in the number of IDUG members - whether conference attendees or not - who identify themselves as application developers and architects). I attended an excellent session on DB2 application design delivered by Jan Henderyckx, a Belgium-based consultant. Jan asked for a show of hands from people who are application developers, and about 40% of the session attendees raised their hands (and Jan had a good-sized audience). A few years ago, it was not unusual to hear programmers speak in a negative way about DBAs, and vice versa. While such us-versus-them attitudes have not entirely gone the way of the dinosaur, seeing so many developers at this IDUG conference is a clear indication of the growing realization that application people and data people need each other. Data is the foundation upon which applications are built, and applications enable organizations to take the value of data from potential to reality.

The second reason for my excitement regarding the application-oriented tilt of the Athens IDUG conference comes from seeing a continuing increase in interest among DB2 DBAs with respect to application-focused conference sessions. I delivered a session on SOA (service-oriented architecture) for DB2 people, and I had a standing-room-only crowd. Again, not so long ago, many DBAs felt that their job responsibility stopped at the DBMS level: manage the data, secure the data, back up the data, provide for CPU-efficient and quick access to the data, and so on. Those are still important matters, but DBAs are now realizing that they can increase the value that they deliver to their employers by helping programmers increase their development productivity - by providing data-access support for a variety of application servers (e.g., WebSphere, WebLogic, Windows .NET), by facilitating data access interfaces that are "natural" for various programming environments (e.g., Java Database Connectivity, or JDBC; ADO.NET, and ODBC), by supporting data access for programs written in different languages (not only COBOL and Java and C#, but newer languages such as Ruby, Python, and Perl), and by helping developers to speed the delivery of functionality by "hiding the data plumbing" (i.e., abstracting the physical particulars of database implementation so that programmers can interact with data using their preferred object view of same). The great news for DBAs is that developers (at least a number with whom I've worked) are often thrilled to have the help of data-centric people when it comes to architecting and building new applications. DBAs, learn about this stuff and watch your popularity grow back at the home office.

At this point, some of you readers may be thinking, "That's great for some, but what about the lot of us who don't get to jet off to Athens (or wherever) to attend an IDUG conference?" No problem. Soon after the conclusion of an IDUG conference, the presentations delivered at event wind up online in the Learning Center section of the IDUG Web site (www.idug.org). And not just slides, mind you, but slides synched with the presenter's audio. Most of these presentations are available only to IDUG members, but basic IDUG membership is free and you can quickly and easily register online at the IDUG site (there is also a premier-level membership, available for a modest annual fee, which provides some exclusive content access and discounts on fee-for-download items). If you're an IDUG member, take advantage of this great learning resource. Those of you who aren't IDUG members should definitely check it out - the price is certainly right.

I hope to see many of you at future IDUG events. Time now for me to start getting ready for the trip back home.

Looking for DB2 Answers?

Everyone who has a DB2-related job - systems programmer, DBA, application developer, manager, consultant - has DB2-related questions. Where do you go for answers? In this post, I'll provide some of my favorite sources of DB2 information. I hope that they will be of use to you. Here we go:

• DB2-L - The DB2 discussion list, sponsored by the International DB2 Users Group (aka IDUG), is a terrific resource for DB2 people. Here's how it works: you join the list at the DB2-L Web page (it's free, thanks to IDUG). Once you've done that, you can send a question to the discussion list, and it will soon reach the other 2300 Listers (as they are commonly known) via e-mail. Generally speaking, someone will respond to your question within an hour or two. The responder could be an experienced DB2 user, a leading DB2 consultant, or even an IBM DB2 developer. Some DB2-L Listers are DB2 for z/OS people, and some are DB2 for Linux, UNIX, and Windows (LUW) people. I have an e-mail folder
  for really good question-and-answer notes, and I end up putting several DB2-L items there almost every business day (it's a pretty active list).
• IDUG member's area - This is the part of the IDUG Web site (www.idug.org) that requires a member login for access. Not an IDUG member? No problem - you can register online and for no charge at the IDUG Web site. Once you're a member, log in to the member's area and take advantage of a slew of information resources, including: discussion forums (these are of the bulletin-board variety, versus the "push" type exemplified by the DB2-L list), the handy e-tip of the week, the Code Place (where IDUG members post useful pieces of code that can help DB2 people do their jobs better and more easily), the Technical Library, and conference sessions (many of these are presentation files synched with the audio from the session). Note that IDUG also has a premier-level membership (included in the registration fee for conference attendees, and available to others for a $100 fee) that provides the earliest access to the most recent conference sessions, and provides a substantial discount off the regular price of recorded sessions available for purchase.
• IDUG Solution's Journal - The "SJ" is the technical magazine published several times per year by the International DB2 Users Group. It's available for free in electronic format at IDUG's Web site (www.idug.org) - just click on the Solutions Journal link near the top of the IDUG home page. SJ articles are packed "news you can use" - stuff aimed at helping DB2 people get the knowledge they need to be better at what they do. Some of the best in the business - IBM DB2 developers, independent consultants, and users - write for the SJ.
• DB2 Magazine - This journal, also free and available online (www.db2mag.com), is another rich source of technical DB2 information, with a heavy contribution by people from the IBM DB2 development organization (IBM sponsors DB2 Magazine). I've been a DB2 Magazine columnist since 2000.
• The DB2 manuals on IBM's Web site - You can access DB2 for z/OS manuals for Version 8 and Version 9.1 (and Version 7, which will go out of service on June 30, 2008). The books can be downloaded to your PC in PDF format, or accessed in HTML form through a browser-based interface (this is my personal preference). Among the manuals I turn to most frequently are the Administration Guide, the Installation Guide, the Application Programming and SQL Guide, and the SQL Reference. Also available on IBM's Web site are manuals for DB2 for Linux, UNIX, and Windows - Version 9 and Version 8.
• IBM's online DB2 for z/OS "space" - This Web site, part of the developerWorks area of IBM.com, provides a varied and rich source of information about DB2 for z/OS.
  
• The planetDB2 blog aggregater - planetDB2 is the place to go to see the latest postings from over two dozen DB2-related blogs (including mine). There's some great stuff here from IBM people and from some top-notch DB2 consultants.
• Google - Yep, I mean the 800-pound gorilla of search engines. Not always the first place to which I turn for DB2 answers, but if I come up empty elsewhere I can sometimes find what I need by typing in a few keywords and sifting through the pile of links returned.

The list above is not exhaustive (there are other Web locations that provide DB2 information), but it does tell you where I often go to get DB2 answers. Get out there, and build up your DB2 smarts.