Db2 Post-Install Setup and System Objects

What “post-install” means

Post-install is not a single job name. It is the moment when the subsystem can start, know its own objects, log changes, lock rows, optionally accept remote clients, and run procedures under WLM. If any of those layers is missing, IVPs and real workloads fail in confusing ways. Use this checklist mentally after DSNTIJxx completes.

Db2 system databases

Db2 system databases hold infrastructure, not business tables. The catalog and directory databases store metadata Db2 needs to resolve SQL and manage objects. The work file database provides space for sorts and temporary results. During install, jobs and CLIST options size these databases; afterward, DBAs monitor growth just as carefully as application databases.

Catalog creation

Catalog creation builds the SQL-queryable dictionary: tables such as those describing tables, columns, indexes, plans, packages, and privileges. You do not CREATE these with ad-hoc DDL in normal operations—the install/migration path creates and maintains them. After CATMAINT (DSNTIJTC), verify catalog level and that basic queries against catalog tables succeed under an authorized ID.

1
2
-- Simple post-install sanity check (authorization required)
SELECT COUNT(*) FROM SYSIBM.SYSTABLES;

Directory creation

Directory creation builds the companion internal store. The directory is not a substitute for the catalog; applications query the catalog, while Db2 uses directory structures for internal control information. Install jobs define and initialize both. Recovery procedures often back up catalog and directory together because they must stay consistent.

Work file database

The work file database supports sorts, created global temporary tables, and other intermediate work. Installation panels (such as DSNTIP9) size 4K and 32K work file table spaces. Undersizing shows up later as sort overflows and poor elapsed times. After install, track work file usage under peak batch and query windows.

BSDS

The BSDS (bootstrap data set) records information Db2 needs about logs and recovery control. Install defines duplexed BSDS data sets via earlier panel choices (DSNTIPA4) and initialization jobs. Protect BSDS like you protect the logs—without it, restart and recovery become much harder. Dual BSDS copies on separate failure domains remain a standard practice.

Active logs

Active logs are the online log data sets written continuously as Db2 records changes. Dual logging (two copies) is the usual production posture. Checkpoint frequency, configured on log-related panels, balances restart time against checkpoint overhead. After install, DISPLAY LOG and monitoring products help confirm log health.

Archive logs

When an active log fills, Db2 archives it according to your archive parameters—often to disk archive data sets and eventually to tape or object storage processes your site uses. Archive retention must match recovery requirements for image copy plus log apply. Post-install, validate that archive allocation works before you need it in an emergency.

Buffer pools

Installation sets initial buffer pool sizes (panels such as DSNTIP1 / DSNTIP2). Buffer pools cache data and index pages in DBM1. Defaults get you started; production tuning adjusts sizes and thresholds using monitoring. Confirm BP0 and other critical pools exist after start, then plan a tuning cycle separate from the install weekend.

IRLM installation

IRLM (Internal Resource Lock Manager) must be available for Db2 locking. Installation jobs such as DSNTIJMV help define the relationship between Db2 and IRLM. Post-install checks include confirming the IRLM address space is up, that Db2 connected to the expected IRLM, and that lock timeouts/deadlock settings match site standards set on IRLM-related panels (DSNTIPI / DSNTIPJ).

DDF setup

DDF setup enables distributed access. Panel values and related jobs configure location name, TCP/IP ports, secure connectivity expectations, and related subsystem parameters. After start, the DIST address space should initialize cleanly for subsystems that use DDF. Test with a simple remote connection in non-production before opening firewall rules widely.

Minimal DDF verification ideas

• Confirm LOCATION and port values match the network request
• Validate authentication and encryption requirements with security
• Exercise a trivial remote SELECT before promoting application traffic

WLM setup

WLM setup creates application environments so stored procedures and UDFs run in managed address spaces. Installation jobs (for example DSNTIJRW and related procedure jobs) establish core environments for Db2-supplied routines. Sites then add environments for local procedures, set goals, and control how many servers WLM starts. Without WLM environments, routine install and CALL statements fail even when SQL tables are fine.

Putting the layers together

A healthy post-install subsystem looks like this: z/OS knows the SSID and procedures; IRLM is up; BSDS and active logs are duplexed; catalog and directory are at the expected level; work files exist; buffer pools are allocated; optional DDF and WLM pieces match the workload you promised in the install plan. Image-copy the catalog/directory (DSNTIJIC), run IVPs, and only then hand the subsystem to application teams.

Handoff checklist for the first week

After the install weekend, schedule a quieter follow-up: confirm archive processing ran at least once, review early statistics and accounting traces if you enabled them, add the subsystem to backup tooling, and document who owns ZPARM changes. Watch for work-file growth during the first heavy batch cycle. If DDF is enabled, review failed connection attempts with security. If routines are installed, confirm WLM starts servers under load rather than only under a single CALL. Post-install success is measured over days, not only by the last job’s return code.

Explain It Like I'm Five

After the clubhouse is built, you check the important rooms. The dictionary room (catalog) lists every toy. The secret office (directory) keeps staff notes. The messy craft table (work files) is where you sort pieces. The diary (logs) and membership book (BSDS) record what happened. Cubbies (buffer pools) keep favorite toys nearby. The hall monitor (IRLM) stops fights over the same toy. The front gate (DDF) lets friends from other streets visit. Helper rooms (WLM) let special projects run without blocking the main hall.

Exercises

1. Explain why catalog and directory backups are often taken together.
2. Describe one symptom of an undersized work file database.
3. List two post-install checks for active logs and BSDS.
4. Why can DDF be optional on one subsystem and mandatory on another?
5. Write a short checklist for verifying IRLM and WLM after first start.