Distributed the term is very big and a lot of information needs to be considered. Although there are many other ways that distributed clients can access DB2, they are entering through other attach types, such as CICS, IMS, MQ, and RRS.
Distributed Systems
These are beyond the scope of this presentation since they are subject to most of the same constraints and monitoring methods as other allied threads. In doubt, situations are also not addressed since that again is a broad subject.
I will begin by covering some of the basic terminologies and attempt to clear up some of the confusing and contradictory usages that is still present in various documents – and also in the instrumentation data itself.
The focus then turns to distributed thread processing modes, the available options and their impact on what you see in thread accounting and DB2 statistics or display output. Interweaved with this discussion is an overview of WLM and distributed enclaves and SRBs.
Then we will look more closely at the instrumentation data available to you to monitor and tune your distributed workloads, focusing on what measures are most important – and why.
DDF and DB2 Considerations
This covers both DDF and DB2 considerations. In the end, we will wrap up the topic by reviewing what impact distributed workloads can have on the critical systems and DB2 resources.
Distributed can refer to the execution platform and refer to Linux, Unix, or Windows (or whatever). It can mean an application that is split across multiple servers or where the user interface, business logic, and database backend reside on different platforms.
Or it can refer to a relational database implementation where the data exists on different platforms and the DBMS facilitates access to the data across the wire.
Basic DBMS concepts.
As you go from top to bottom the functionality and complexity increase. With Remote Request, we’re talking a single statement against a single remote database instance/subsystem.
With Remote Unit of Work, we add multiple statements against multiples tables into the mix; however, we’re still focused on a single DB2 or relational instance.
With Distributed Unit Work we are able to access multiple DB2s in a single UOW (Unit of Work). Each SQL statement can only access a single DB2. Distributed UOW introduces the requirement for the two-phase commit protocol. I have to be able to commit or rollback all DBMS changes in the UOW at the same time.
Distributed Request is nirvana.
In this case, a single SQL statement can access/join tables from multiple distributed platforms. This capability does not exist in the native DB2 engine; however, IBM does offer this capability with its federated database servers.
- Connect to DB2 using System Directed Access. This is done by providing a three-part name, either directly through the SQL or by referencing an alias that resolves to a three-part name. In this scheme, the first node of the three-part name references the DB2 location where the data is stored. As mentioned, both PP and DRDA protocols are supported. More on that later. Examples are provided;
- The second option is that the application issues an explicit CONNECT statement in the application and specifies the target DB2 to connect to.
- The Remote Stored Procedure call is a third common kind of implementation I see. In this case, the distributed requester/client does and explicit CONNECT and the issues a call to the stored procedure, passing the required data. Some customers limit the ability of the requester to use anything but stored procedure calls.
A very short history!
The first DDF (Distributed Data Facility) only provided access from one mainframe DB2 to another and was first delivered in DB2 V2R2.
Note: Any reference to DB2 is shorthand for DB2 for z/OS.
main view for DB2 is sometimes shortened to MVDB2.
The DRDA protocol (level 1) was first implemented in DB2 V2R3, providing the first client/server access. DB2 V4 was a significant step forward, with DRDA supported stored procedures to reduce network traffic, an increased number of supported connections (25,000), and DBATs processing with different priorities (not just as standard DIST SRBs).
DB2 V5 (with DRDA level 3) supported TCP/IP, ODBC, CLI and JDBC, and DDF enhancements have continued to be delivered in every DB2 release. Concurrently, the original DDCS has been growing up into DB2 Connect.
Now we are seeing web-based access coming of age and changing rapidly, with Java applications, the DB2 SQLJ and JDBC Universal Driver, Websphere, and other AR/AS servers between the remote clients and DB2 for z/OS (like SAP).
One of the problems with understanding DDF is that the terminology hasn’t always kept up with the rapid changes, and can often be confusing and inconsistent.
Part of this is historical, with the swift migration from simple DB2 to DB2, to the current wealth of connectivity options and frequent enhancements in DB2 for z/OS.
Another issue arises from the culture clash between the mainframe and distributed worlds, compounded by the many new distributed clients and access methods.
Srinimf 