Skip to main content

How Atlan connects to IBM Db2 for z/OS

TL;DR

Understand how Atlan securely connects to your IBM Db2 for z/OS subsystem to extract metadata.

Connect

Atlan connects to your IBM Db2 for z/OS subsystem to extract technical metadata while maintaining network security and compliance. You can choose between Direct connectivity for subsystems reachable from the internet or Self-Deployed Runtime for subsystems that must remain behind your firewall.

Connect via direct network connection​

Atlan's IBM Db2 for z/OS workflow establishes a direct network connection to your subsystem from the Atlan SaaS tenant. This approach works when your Db2 Distributed Data Facility (DDF) can accept connections from the internet.

Direct extraction

  • Atlan's IBM Db2 for z/OS workflow connects directly to your DDF listener from the Atlan SaaS tenant over port 446 (default), using the IBM Data Server Driver for JDBC and SQLJ (the jcc type 4 driver) over DRDA.
  • Your DDF listener accepts inbound network connections from Atlan's IP addresses, controlled through your firewall rules or network security groups.
  • You can encrypt the connection with SSL/TLS by uploading a JKS or PKCS12 truststore, or by uploading the server or certificate authority (CA) certificate directly as an .arm or .pem file, when configuring the crawler.

For details on how direct connectivity works, see Direct connectivity.

Connect via self-deployed runtime​

A runtime service deployed within your network acts as a secure bridge between Atlan Cloud and your Db2 for z/OS subsystem. This approach works when your subsystem must remain fully isolated behind your firewall.

Self-deployed runtime extraction

  • The runtime maintains an outbound HTTPS connection to Atlan Cloud (port 443) and a local network connection to your DDF listener (port 446 by default).
  • The runtime translates requests into read-only SQL queries, runs them against the Db2 system catalog, and returns the extracted metadata to Atlan Cloud.

For details on how Self-Deployed Runtime works, see SDR connectivity.

Connection behavior​

  • The connector addresses your subsystem by its DRDA location name, which it sends as the database element of the connection URL. A single connection sees the whole subsystem, so one connection is enough to crawl every database and schema in scope.
  • Db2 for z/OS models databases and schemas as peers rather than as a strict hierarchy, because a schema's tables can span multiple databases through their table spaces. Atlan reflects this by linking each schema to every database whose tables it owns, instead of nesting the schema under a single database.
  • The connector runs its catalog queries sequentially rather than in parallel, which respects the limit your subsystem places on concurrent DRDA sessions.
  • Lineage comes from the SQL definitions of views, stored procedures, and functions - the connector parses the SQL text the subsystem records for each of them to build lineage between assets. Query history mining isn't supported for Db2 for z/OS.

Security​

Atlan extracts only structural metadata - databases, schemas, tables, views, columns, and the definitions of views, stored procedures, and functions. For example, if you have a CUSTOMERS table with customer records, Atlan discovers the table structure and column definitions, but never queries or stores the customer records themselves.

  • Read-only operations: All queries are read-only SELECT statements against the Db2 system catalog. The connector can't modify data, create or drop objects, or change any configuration. The Db2 privileges you grant control exactly what the connector can access.

  • Credential encryption: Db2 connection credentials are encrypted at rest and in transit. In Direct connectivity, Atlan encrypts credentials before storage. In Self-Deployed Runtime, credentials never leave your network perimeter - the runtime retrieves them from your enterprise-managed secret store only when needed, and Atlan Cloud never receives or stores them.

  • Network isolation with Self-Deployed Runtime: Your subsystem gains complete network isolation from the internet. DDF only accepts connections from the runtime within your local network. The runtime itself only makes outbound HTTPS connections to Atlan Cloud, which your network team can control through firewall rules.

See also​