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.
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.
posted by Robert Catterall at
8:42 PM
2 Comments:
Bob, good discussion of the topic. Thanks for the recommendations.
Glad you found the post to be useful. Thanks for the positive feedback.
Robert
Post a Comment
Subscribe to Post Comments [Atom]
<< Home