DB2 DDF architecture and connectivity

Where DDF sits in the subsystem

A Db2 subsystem is several address spaces. For distributed SQL:

• ssnmDIST — DDF: sockets, DRDA parsing, thread pooling, enclaves
• ssnmDBM1 — database services: buffer pools, space management, the actual GETPAGE
• ssnmMSTR — system services: start/stop, logging coordination
• IRLM — locks, including global locks if you are in a data sharing group

A remote request arrives on a TCP port in DIST. DIST creates or borrows a database access thread (DBAT) and passes the SQL to DBM1. You still COMMIT, still take locks, still write log records. DDF is the front door, not a second database.

IBM documents very large connection counts (CONDBAT up to 150000 with inactive connections) and a smaller number of concurrent DBATs (MAXDBAT; CTHREAD + MAXDBAT must stay within the documented cap, historically 20000). Connections and threads are not the same thing—the threads page goes deep on that.

DRDA, TCP/IP, and VTAM

DRDA (Distributed Relational Database Architecture) is the standard that lets a Db2 for z/OS server talk to IBM clients and to other DRDA servers. The payload is SQL, describes, and commits—not a private 3270 datastream.

TCP/IP is the network almost every new client uses: host name or DVIPA, port, optional TLS. VTAM / SNA used LU names (LUNAME, GENERICLU) and still appears in BSDS and DSNL004I. New work should assume TCP/IP. SNA matters when you inherit a partner that never moved.

Stored procedures help DDF: one network message can run many SQL statements at the server. Block fetch ships result rows in chunks. That is why a chatty row-by-row JDBC loop feels slow on z/OS compared with a single CALL.

LOCATION, IPNAME, and ports

The location name is how SQL names this server: CONNECT TO DB2PROD or DB2PROD.HR.EMPLOYEE. In a data sharing group the location usually names the group, not one member, so clients can land on any member. Location aliases can point at a subset of members (for example only the query members). Maintain aliases with DSNJU003; verify with DSNJU004. After member consolidations, remove dead members from aliases or workload balancing misbehaves.

IPNAME is the TCP/IP name Db2 uses for itself in DRDA. Combined with DOMAIN on DSNL004I it is how partners find you. Sysplex distributor / DVIPA is how you give one IP to the whole group.

If PORT shows as unavailable, a common cause is MAXDBAT=0 (DDF will not accept SQL threads) or a BSDS PORT of 0. Members of a group should use the same DRDA port and the same SECPORT. Unique per-member secure ports break sysplex workload balancing. RESPORT may be unique per member because resync has to find the member that still owns the unit of recovery.

1
2
3
4
5
6
7
-START DDF
-STOP DDF
-STOP DDF MODE(QUIESCE)
-DISPLAY DDF DETAIL
 
/* After DDF start, look for DSNL004I:
   LOCATION, TCPPORT, SECPORT, RESPORT, IPNAME, PKGREL */

Requester, database server, application server

The same subsystem is often all three in one day: CICS is local (allied), a JDBC farm treats it as the database server, and a three-part name to a warehouse Db2 makes z/OS a requester. Communications database (CDB) tables such as SYSIBM.LOCATIONS, SYSIBM.IPNAMES, and SYSIBM.USERNAMES tell a requester how to reach a remote LOCATION.

DRDA packages

Type 4 JDBC and ODBC do not precompile your Java. They bind IBM-supplied DRDA packages (collection NULLID is the usual example) on the server. GRANT EXECUTE on those packages to the runtime authids. When a client “cannot execute package NULLID.SYSxxx” you are missing a bind or a grant, not a table.

PKGREL on DSNL004I (BNDOPT, BNDPOOL, COMMIT) controls how DDF honors package RELEASE options when a high-performance DBAT finishes. That knob sits on the boundary between connectivity and thread pooling.

DDF threads in one paragraph

Each active remote transaction needs a DBAT. Inactive connections can wait without a DBAT (CMTSTAT INACTIVE). Allied threads (CICS, IMS, TSO, batch) are a different pool (CTHREAD). Protected CICS threads are an attachment topic; DDF has its own pool. The next two pages cover remote SQL and then DBATs in depth.

TCP/IP security, authentication, and encryption

Treat the open DRDA port as a production door:

• Authentication — user ID and password, RACF PassTickets, client certificates, Kerberos, or trusted contexts that map a system AUTHID to a role
• Encryption — TLS on SECPORT (AT-TLS or Db2 SSL support). Prefer SECPORT in production; do not assume the SQL port is private
• TCP/IP security — policy filters, DVIPA, and which networks may route to the DRDA ports
• Authorization still happens inside Db2 after connect: packages, tables, and roles. Connecting is not SELECT *

The dedicated DDF security page covers TLS setup and remote authorization in more detail. For this architecture page, remember: identity on the wire, encryption on SECPORT, then ordinary Db2 privileges.

Explain It Like I'm Five

DDF is the front desk of the Db2 library. DRDA is the language visitors speak. TCP/IP is the street they walk on; VTAM is the old tram still running for some neighbors. The LOCATION is the library’s name on the map. PORT is the public door, SECPORT is the door with a lock and a secret handshake, RESPORT is the special door for “we got cut off in the middle of returning two books at once.” DIST is the receptionist; DBM1 is the stacks. JDBC drivers bring a library card (DRDA packages) so they are allowed to ask for books without writing COBOL.

Exercises

1. Find DSNL004I or DISPLAY DDF on a test system and write down LOCATION, PORT, SECPORT, and IPNAME.
2. Explain why a data sharing group wants one LOCATION and shared PORT/SECPORT but per-member RESPORT.
3. Is your laptop JDBC a requester or a server? Is z/OS the database server?
4. A Java error mentions NULLID. What do you check first?
5. Why might START DDF appear to work but refuse connections when MAXDBAT is 0?