Set up DB2 DDF

Set up DDF

DDF runs in the ssnmDIST address space. Clients speak DRDA, almost always over TCP/IP today. The subsystem advertises a LOCATION name that SQL CONNECT and three-part names use, plus listener ports for ordinary SQL, secure SQL, and resynchronization. Those values live in the BSDS DDF communication record. Installation panels and post-install jobs may set initial values; DSNJU003 changes them later.

A usable DDF setup also depends on z/OS TCP/IP, DNS or DVIPA names, TLS policy when secure ports are used, WLM classification for DDF work, and DB2 parameters such as MAXDBAT and CONDBAT. You can have a listener that starts cleanly and still refuse useful work if those surrounding pieces are wrong. Treat network identity, DB2 configuration, and client package setup as one project.

In data sharing, clients usually connect to the group location, not to one member's private identity. Members should share the same DRDA PORT and SECPORT values so sysplex distributor / workload balancing behaves. RESPORT may remain unique because resync must find the member that owns a unit of recovery.

Prerequisites

• DB2 subsystem (or data sharing group) already installed and able to start locally
• Planned LOCATION name that will not collide with other servers your clients can see
• Reserved TCP ports for PORT, SECPORT (if used), and RESPORT, approved by network and security teams
• TCP/IP host name or DVIPA strategy, and TLS materials if SECPORT or required encryption is in scope
• Authority to run DSNJU003 against the correct BSDS pair, start DDF, and issue DISPLAY DDF
• A test client (JDBC, DSN command remote CONNECT, or approved tool) for verification

Steps

Step 1: Decide location, ports, and IP identity

Choose a LOCATION that applications will use in CONNECT and documentation. Pick PORT for standard DRDA SQL, SECPORT if clients must hit a listener that demands TLS, and RESPORT for XA / two-phase resync. Decide IPNAME / IPV4 / IPV6 / group IP values with your network standards. Write these choices down before editing BSDS so every member and every document uses the same numbers.

Also review subsystem parameters that gate distributed work. MAXDBAT controls how many database access threads DDF can use. If MAXDBAT is 0, DDF will not accept SQL threads even when the address space starts. CONDBAT and related DDF parameters belong in the same planning pass.

Step 2: Update the BSDS DDF record with DSNJU003

Use the change log inventory utility against both BSDS copies for the subsystem. A typical control statement sets location and ports together. Exact keywords depend on your DB2 version and whether you are adding or updating the communication record. Coordinate outages: BSDS changes are serious and must follow site change control.

1
2
3
4
5
6
7
8
9
//DSNTLOG  EXEC PGM=DSNJU003,COND=(4,LT)
//STEPLIB  DD DISP=SHR,DSN=DSN.V13R1M0.SDSNLOAD
//SYSUT1   DD DISP=OLD,DSN=DSNCAT.BSDS01
//SYSUT2   DD DISP=OLD,DSN=DSNCAT.BSDS02
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DDF LOCATION=DB2PROD,PORT=446,SECPORT=448,RESPORT=5001
  DDF IPV4=10.1.2.3
/*

Print the BSDS with DSNJU004 afterward and confirm the DDF record shows the intended LOCATION and ports. If you maintain aliases for subsets of a data sharing group, add those deliberately and document which members each alias includes.

Step 3: Prepare TCP/IP, TLS, and WLM

Ensure the z/OS TCP/IP stack allows inbound connections on the chosen ports. Register DNS or DVIPA names that clients will use. For SECPORT or required ATLS, complete ATLS policy and certificate work with your security administrators before promising secure connectivity. Place the DIST address space in an appropriate WLM service class—commonly alongside other DB2 system address spaces—and classify DDF transactions according to site performance standards.

Step 4: Start DDF and read the startup messages

Start DDF with the DB2 command your site uses, typically -START DDF. Watch for DSNL004I, which reports LOCATION, DOMAIN, TCPPORT, SECPORT, RESPORT, IPNAME, and options such as PKGREL. If startup fails, collect the DSNL0xx messages named in the documentation for your release and fix the underlying TCP/IP or BSDS issue before retrying.

1
2
3
4
5
6
7
8
9
-START DDF
-DISPLAY DDF
-DISPLAY DDF DETAIL
 
Look for:
  STATUS=STARTD
  LOCATION = expected name
  TCPPORT / SECPORT / RESPORT = expected values
  SQL DOMAIN / IPADDR present for TCP/IP

Step 5: Bind or confirm distributed packages and authorization

Remote clients need packages on the server collections your driver or requester expects, plus EXECUTE authority for the authids those clients use. Site standards often include NULLID or vendor collections for JDBC/CLI packages. Confirm GRANTs and package existence before blaming the network when a first connection fails with package-not-found symptoms.

Step 6: Run a controlled client connection test

From an approved workstation or middleware tier, connect using the LOCATION or host name, the correct port, and test credentials. Run a trivial SQL statement such as selecting from SYSIBM.SYSDUMMY1. Then test the secure port if it is part of the design. In data sharing, repeat against the group distributor name and confirm work can land on healthy members.

1
2
3
4
5
6
Verification ideas:
  1) DISPLAY DDF DETAIL shows STARTD and expected ports
  2) Client connects to host:446 (or your PORT)
  3) SELECT CURRENT SERVER FROM SYSIBM.SYSDUMMY1
  4) Secure client connects to SECPORT when configured
  5) -DISPLAY THREAD(*) shows the distributed thread while connected

Verify results

1. DSNJU004 or equivalent BSDS print matches the intended LOCATION and port values.
2. DSNL004I / DISPLAY DDF show STATUS=STARTD with the same values.
3. A non-secure client test succeeds on PORT when that path is approved.
4. A secure client test succeeds on SECPORT when secure access is required.
5. MAXDBAT and related DDF limits are nonzero and sized for the expected workload.
6. Runbooks list LOCATION, ports, DNS/DVIPA names, and who owns TLS certificates.

Common errors

Another common mistake is configuring only one member of a data sharing group and assuming the group location will work. Every member that should accept distributed work needs a coherent DDF record, TCP/IP path, and startup procedure. Likewise, do not publish a SECPORT to application teams before ATLS is actually ready; clients will fail in ways that look like random network defects.

Finally, remember that DDF setup is not finished when DISPLAY DDF looks pretty. Until a real client authenticates, finds packages, and runs SQL, you have only proven the listener. Keep the client test in the definition of done.

Explain it like I'm 5

DB2 DDF is the front door and doorbell for programs that do not sit on the mainframe screen. The LOCATION is the house name on the mailbox. The PORT numbers are doorbell buttons—one ordinary button, one special locked button for safer visits, and one service button for finishing shared chores. Setting up DDF means writing the house name and doorbell numbers in the official address book (the BSDS), making sure the street (TCP/IP) reaches the door, opening the door with START DDF, and then asking a friend outside to ring the bell and say hello with a tiny SQL request.

Exercises

1. Draft a DSNJU003 SYSIN that sets LOCATION DB2TEST, PORT 446, SECPORT 448, and RESPORT 5001. List what you would verify with DSNJU004.
2. Explain why data sharing members usually share PORT and SECPORT but may use unique RESPORT values.
3. Write a verification checklist that includes DISPLAY DDF DETAIL and a client SELECT.
4. Describe what you would check if DDF shows STARTD but MAXDBAT is 0.
5. Create an ownership matrix: network, security, DB2 DBA, and application team responsibilities for a new DDF go-live.