Db2 Installation Planning

Why planning comes before the CLIST

The installation CLIST is excellent at capturing answers and writing consistent JCL. It cannot invent your site standards. If you invent names, SMS classes, and security IDs on the fly while sitting in ISPF, you will regenerate jobs repeatedly and still risk mismatches with RACF profiles, ICF catalogs, and operations runbooks. Treat planning as a short design phase: document decisions, get storage and security teams aligned, then open DSNTINST to encode those decisions.

Planning also separates two different activities that people casually call “install.” First, SMP/E makes Db2 product code available on the system. Second, the subsystem install defines VSAM system data sets, ZPARMs, catalogs, procedures, and verification. This tutorial focuses on planning the second activity after product libraries already exist.

Prerequisites you should confirm

Product libraries

Before generating jobs, confirm that SMP/E has installed the libraries the CLIST and panels need. At minimum for interactive CLIST work you need:

• prefix.SDSNCLST — contains DSNTINST and related CLISTs
• prefix.SDSNSPFM / SDSNSPFP — ISPF messages and panels
• prefix.SDSNSAMP — sample jobs and default members such as DSNTIDXA
• prefix.SDSNIVPD — only if you generate z/OSMF provisioning artifacts

You will also rely on SDSNLOAD and related runtime libraries when address spaces start. Confirm the high-level qualifier and suffix your site uses for Db2 12 or Db2 13 FMIDs so panel fields like LIBRARY NAME PREFIX match reality.

z/OS and coupling readiness

Confirm DASD or SMS capacity for catalog, directory, BSDS, active logs, archive logs, work files, and image copies. If you plan data sharing, confirm coupling facility structure sizing and naming conventions with the sysplex team. IRLM must be available as the lock manager for Db2. Decide whether PARMLIB updates from DSNTIJMV can be activated dynamically or will require an IPL window.

Security and ownership

Agree which authorization IDs will hold install SYSADM or installation SYSOPR roles, which IDs own started tasks, and how RACF (or equivalent) profiles will protect Db2 resources. Planning these IDs early prevents half-built subsystems that only the person who typed the panel can administer.

Core planning decisions

Write the subsystem identifier (SSID), procedure names, and high-level qualifiers in one place. Those strings ripple into DSNTIJMV procedures, data set names, DDF LOCATION, and monitoring filters. Changing them after jobs are generated is possible but painful.

The installation CLIST in the plan

The installation CLIST is IBM’s supported way to tailor installation and migration JCL. You run it under ISPF (typically option 6) after allocating enough TSO region—about 2 MB is usually enough. The CLIST presents a long series of panels. Most fields correspond to subsystem parameters or object defaults. When you finish, it writes tailored jobs into output libraries such as your NEW.SDSNSAMP and temporary libraries.

1
2
3
4
5
/* Typical interactive invocation under ISPF Command Shell */
EXEC 'DSN1310.SDSNCLST(DSNTINST)'
 
/* Optional: more verbose CLIST tracing */
EXEC 'DSN1310.SDSNCLST(DSNTINST)' 'CONTROL(LIST)'

Interactive mode is the usual teaching path. Background mode exists for automation, and z/OSMF workflows can be generated when you select provisioning options. For a first install, interactive mode helps you see how each answer maps to a field.

DSNTINST and the main panel mindset

DSNTINST opens on panel DSNTIPA1 (or a related main panel in some provisioning paths). Treat DSNTIPA1 as the control room for the whole session:

• INSTALL TYPE — INSTALL for new, MIGRATE for release-to-release, ACTIVATE for function levels, UPDATE for parameter refresh, PROVISION for z/OSMF-oriented builds
• DATA SHARING — YES or NO shapes later panels and job content
• LIBRARY NAME PREFIX / SUFFIX — where SMP/E product libraries live
• DATA SET NAME PREFIX / SUFFIX — where tailored NEW libraries go
• INPUT MEMBER NAME — defaults member such as DSNTIDXA
• OUTPUT MEMBER NAME — where your session answers are saved

Save progress with the CLIST SAVE flow as you go. If the session fails or you need to stop, you can restart using the output member instead of retyping everything. For migration, the DATA SET(MEMBER) NAME field points at settings captured from the prior release.

Using an existing subsystem as a planning template

If you already have a Db2 subsystem, run the capture job that invokes the DSNTXAZP tool (commonly DSNTIJXZ). It updates a CLIST defaults input member with current subsystem parameter settings, buffer pool settings, and related installation values. That reduces manual comparison between an old DSNTIJUZ and a blank defaults member. For green-field installs you still start from IBM’s sample defaults, but review every size and name against your capacity plan.

Sizing and calculation panels

On sizes panels such as DSNTIPD you describe the expected environment with integer values. You can often use K and M suffixes for byte multiples. The CLIST calculates storage requirements and shows results on calculation panels such as DSNTIPC. Planning means bringing realistic concurrency, object counts, and growth assumptions—not copying textbook defaults into production. Override calculated values only when you understand the consequence for virtual storage and DASD.

People, windows, and verification

Technical answers are only half of planning. Name the change owner, the system programmer who will apply PARMLIB updates, the security administrator who will create profiles, and the DBA who will run IVPs. Agree whether the first start is in a sandbox LPAR or a shared sysplex. Book a fallback conversation before the weekend starts—even a green-field install benefits from a written “if start fails, we do X” note. Include how you will prove success: DISPLAY commands, sample SPUFI selects, a remote connection test if DDF is in scope, and a stored-procedure smoke test if WLM routines are required on day one.

Also plan communication: operators need the new SSID and procedure names in their runbooks; monitoring teams need the subsystem added to dashboards; application teams need the location name and bind rules. Installs fail socially when the engine is up but nobody outside the DBA team knows how to use it.

What good planning documents look like

A useful install plan is short enough that people read it. Include:

• Target Db2 version and whether this is install or migrate
• SSID, procedures, HLQs, catalog alias, and location name
• SMS / volume strategy for catalog, logs, work files, and copies
• IRLM, DDF, and WLM environment expectations
• Security IDs and who runs which jobs
• Change window, fallback expectations, and IVP ownership
• Link to the output defaults member after the CLIST session

After planning, your next learning steps are the DSNTIPxx panel walkthrough and the DSNTIJxx job sequence. Those pages assume you already know why each name and size was chosen.

Explain It Like I'm Five

Imagine building a big clubhouse. Before you hammer boards, you decide the name of the clubhouse, where the toolbox goes, who has the keys, and how many shelves you need. The installation CLIST is like a helper with a checklist who writes shopping lists (jobs) after you answer those questions. DSNTINST is the helper’s name. Planning is deciding the answers before the helper starts asking, so you do not build three different clubhouses by accident.

Exercises

1. List five decisions you would write down before running DSNTINST for a new test subsystem.
2. Explain the difference between SMP/E product install and Db2 subsystem install in two sentences.
3. Write the ISPF command you would use to start DSNTINST from a library named DSN1310.SDSNCLST.
4. When would you choose INSTALL versus MIGRATE on DSNTIPA1?
5. Describe one reason to capture an existing subsystem with DSNTIJXZ before planning a similar new member or sandbox.