Thread: Python on z/OS

z/OS Python calling DB2 via ibm_db - connection pooling question

Started by Priya • user3 replies96 viewsLast activity 2 weeks ago
Post #1
0 votes
Priya
Reputation
56
Posts: 8
Joined: Aug 17, 2025, 2:03 PM
Posted: Jun 23, 2026, 1:08 PM

Dear forum,

I am prototyping a small z/OS Python utility to extract exception queue metrics into a dashboard. The script uses ibm_db and currently opens a new connection for each SQL statement:

python
import ibm_db

conn_str = (
    "DATABASE=DB2P;HOSTNAME=lpar01.example.com;"
    "PORT=5045;PROTOCOL=TCPIP;UID=PYMETR;PWD=*;"
)

def fetch_count(sql):
    conn = ibm_db.connect(conn_str, "", "")
    stmt = ibm_db.exec_immediate(conn, sql)
    row = ibm_db.fetch_assoc(stmt)
    ibm_db.close(conn)
    return row

Performance is acceptable for a proof of concept but I am concerned about production load. The IBM documentation for ibm_db notes:

Connection objects should be reused where possible to reduce attach overhead on Db2 for z/OS.

Would a single long-lived connection per batch invocation be the recommended pattern, or does your site use a connection pool layer outside Python?

Best regards,
Priya

Post #2
0 votes
Elena
Reputation
391
Posts: 6
Joined: Apr 18, 2024, 9:30 AM
Posted: Jun 23, 2026, 4:08 PM

One connection per job step is appropriate for batch utilities. Open at start, close before step end. Ensure the DB2 authorization ID is dedicated and audited.

Pooling is more relevant for long-running daemons, which we generally avoid on z/OS Python unless operations signs off.

Post #3
0 votes
Priya
Reputation
56
Posts: 8
Joined: Aug 17, 2025, 2:03 PM
Posted: Jun 23, 2026, 8:08 PM

Thank you. I refactored to a single connection per invocation and added explicit ibm_db.close in a finally block. Latency improved noticeably on a ten-query run.

You must be signed in to reply to this thread