What is Db2 for z/OS?

Introduction

On a mainframe shop floor you will hear people say “check Db2,” “the Db2 subsystem is down,” or “bind the package to Db2.” Those phrases refer to a product family and, more specifically on IBM Z, to Db2 for z/OS: software that manages relational databases. Unlike a simple sequential file or a VSAM KSDS that one program “owns” for a job step, Db2 is designed so many online transactions and batch jobs can share the same tables with locking, logging, and recovery built in.

IBM offers several Db2-branded products for different platforms. This tutorial series focuses on Db2 for z/OS, the edition that runs as part of the z/OS operating system on IBM Z hardware. Later pages compare it with Db2 for Linux, UNIX, and Windows (often called Db2 LUW) and with Db2 for i, so you do not confuse brand names with identical products.

Learning Db2 is valuable whether you write COBOL, maintain JCL that runs utilities, or support CICS transactions. Developers need SQL and host-variable patterns. Operators need to recognize subsystem messages and utility failures. Analysts need to understand tables, keys, and set-based queries. Everyone benefits from a clear picture of what Db2 is and what problem it solves.

What is Db2 for z/OS?

At its core, Db2 for z/OS is a relational database management system (RDBMS). That means:

• Data is organized logically as tables—named collections of rows and columns—not as free-form text or as hierarchical segments only.
• Applications access and change data primarily with SQL (Structured Query Language): SELECT, INSERT, UPDATE, DELETE, and data-definition statements such as CREATE TABLE.
• The DBMS—not each application—enforces many integrity and concurrency rules: unique keys, referential constraints, check constraints, locks, commits, and rollbacks.
• The system keeps logs and recovery information so committed work can survive failures and so incomplete work can be undone.

IBM’s documentation describes Db2 for z/OS as the enterprise data server for IBM Z: it manages core business data, stays continuously available for many customers, and scales under heavy concurrent load. That is why critical online banking and reservation systems often sit on Db2 for z/OS rather than on a single desktop database.

Relational data in plain terms

In a relational database, you picture data as one or more tables. Each table has a fixed set of columns (for example CUSTOMER_ID, NAME, CITY) and a varying number of unordered rows. Relationships between tables are expressed with keys—for example an ORDER row stores a CUSTOMER_ID that matches a row in CUSTOMER—rather than by navigating parent/child pointers the way older hierarchical databases did. Db2 can enforce those relationships with referential integrity so orphan order rows cannot appear without a matching customer, if your design defines that rule.

Tables are the application-facing view. Under the covers on z/OS, Db2 also uses objects such as table spaces, indexes, storage groups, and buffer pools. You will learn those in later lessons; for now, remember that “table” is how you think about data when you write SQL, while “table space” and related objects are how Db2 stores and caches that data on the mainframe.

Db2 as a z/OS subsystem

On z/OS, Db2 does not run as a casual user program you start from ISPF Option 6 for every query. It runs as a formal subsystem: a named, system-recognized service that can operate independently of, or asynchronously with, the rest of the system. Each Db2 instance has a subsystem identifier (SSID), often four characters such as DB2P or DB2T for production and test.

When operators start Db2, z/OS creates several address spaces that split the work. A typical picture includes system services (logging, commands, checkpoints), database services (SQL processing, buffer pools, data access), a distributed data facility for remote clients, and the Internal Resource Lock Manager (IRLM) for locks. Stored procedures and user-defined functions often run in Workload Manager (WLM) managed address spaces. You do not need every detail on day one, but you should know that “Db2 is up” means a coordinated set of address spaces is serving SQL for that SSID.

1
2
3
4
5
6
7
8
9
Example mental model (names vary by site):
 
  z/OS LPAR
    └── Db2 subsystem SSID=DB2P
          ├── DB2PMSTR   system services, logging, commands
          ├── DB2PDBM1   database services, buffer pools, SQL engine
          ├── DB2PDIST   distributed (DDF) remote access
          ├── DB2PIRLM   lock manager
          └── WLM ASs    stored procedures / UDFs (as configured)

How applications use Db2

Programs connect to a Db2 subsystem through attachment facilitiesappropriate to their environment: TSO/batch, CICS, IMS, RRSAF, and others. Online CICS transactions often share threads managed by the CICS-Db2 attachment. Batch COBOL jobs typically use the TSO or batch attachment and a plan or package that was bound after precompile. Remote applications can connect through the Distributed Data Facility (DDF) using DRDA over TCP/IP.

Regardless of attachment, the application language for data access is SQL. In COBOL you usually embed statements like this:

1
2
3
4
5
6
7
8
9
10
11
       EXEC SQL
            SELECT CUST_NAME
              INTO :WS-CUST-NAME
              FROM CUSTOMER
             WHERE CUST_ID = :WS-CUST-ID
       END-EXEC.
       IF SQLCODE = 0
           DISPLAY 'FOUND ' WS-CUST-NAME
       ELSE
           DISPLAY 'SQLCODE=' SQLCODE
       END-IF.

The colon-prefixed names are host variables—COBOL fields that carry values into and out of SQL. After each executable SQL statement, Db2 fills the SQL Communication Area (SQLCA). A SQLCODE of 0 means success; negative values indicate errors; +100 often means “no row found” for a singleton SELECT. Checking SQLCODE is not optional in production-quality programs.

What Db2 manages beyond “just tables”

A Db2 database system is more than a pile of CREATE TABLE statements. It includes structures that store data and processes that run when applications access that data. Important ideas for beginners:

Db2 also provides utilities (LOAD, REORG, COPY, RECOVER, RUNSTATS, and many others) that run as batch jobs or stored procedures to maintain physical organization, take image copies, and gather statistics for the optimizer. Administration and application development are different skill tracks, but both start from understanding that Db2 owns the data lifecycle—not only the SQL SELECT you write today.

Transactions, integrity, and concurrency

Business updates rarely happen one field at a time in isolation. Transferring money might require debiting one account and crediting another. Db2 groups related changes into a unit of work. COMMIT makes the changes permanent; ROLLBACK undoes them. In CICS, syncpoint coordinates Db2 changes with other CICS resources so the whole transaction commits or rolls back together.

While many users update overlapping data, Db2 uses locks (via IRLM) so readers and writers do not corrupt each other’s view. Isolation levels and lock duration affect how much concurrency you get versus how strict your read consistency is. Beginners should remember the principle: Db2 is built for shared update, not for “one job owns the file exclusive.”

Who works with Db2 for z/OS?

This Getting Started section aims at beginners who need the big picture before diving into CREATE TABLE syntax or bind options. If you are a developer, prioritize SQL, host variables, and SQLCODE. If you are aiming at DBA work, still learn SQL first—every performance and design discussion eventually returns to how applications query the data.

Db2 compared with files you already know

Mainframe developers often know QSAM and VSAM before Db2. Files are still important for extracts, interfaces, and some master files. Db2 complements them when you need:

• Ad hoc and flexible queries without rewriting a program for every report layout
• Many concurrent updaters with recovery and integrity rules
• A shared catalog of column definitions and privileges
• Distributed access from mid-tier or cloud applications into the same trusted data

Shops often move interface files through DFSORT or Easytrieve and keep authoritative balances in Db2. Understanding both worlds makes you more effective on real projects.

Explain It Like I'm Five

Imagine a giant shared toy box that every kid in the school can use. If everyone just grabbed toys and threw them back anywhere, the box would become a mess and two kids might fight over the same toy. Db2 is like a careful teacher who keeps the toys in labeled drawers (tables), writes down every borrow and return (the log), and makes sure only one kid changes a special toy at a time when needed (locks). When you want a red car, you ask politely in a special sentence (SQL) instead of dumping the whole box on the floor. When you are done playing a game that used two toys together, you either keep both changes (COMMIT) or put everything back as it was (ROLLBACK).

Exercises

1. In one or two sentences, explain how a relational table differs from a sequential file that your COBOL program reads from start to end.
2. Your site’s production Db2 SSID is DB2P. List three address-space roles you would expect to hear about when someone says “Db2 is up,” and what each roughly does.
3. A COBOL program selects one customer name into a host variable. What should the program check immediately after the EXEC SQL block, and why?
4. Give one reason a bank might store account balances in Db2 instead of only in a VSAM KSDS updated by a single nightly batch job.
5. Write a tiny SQL SELECT (on paper) that reads a column from a table named EMPLOYEE using an employee id predicate. Then rewrite it as a conceptual COBOL EXEC SQL ... END-EXEC block with a host variable.