Triton Db2 Geek

Confessions of a DB2 geek

IBM Gold Consultant Program and IBM Premier business Partner

Enumerating DB2 Subsystems

November 27th, 2014 - by


Every site has this challenge and we all find different ways around the problem: How can I generate a list of DB2 subsystems defined to my current LPAR and whether they are active or not?

It may be that you want to know exactly that but more commonly this is the sort of thing that is needed to support a DB2 tools panel, validating which services are genuinely available.

Typically we find that customers resort to hard coded lists in the panel verification e.g.


In this example we have three DB2s listed (DG91,DGA1 and DGB1) which all happen to be the first members of data sharing groups.  What happens if we need to run the second member of DB90 (DG92) on this LPAR? What if we create a new data sharing group?

Determining what DB2 services are defined to your LPAR can be done in a number of ways.  This blog outlines an approach which can be used on any site with DB2 for z/OS.

Some Control Blocks

Inevitably, finding this information will require some gentle control block surfing.  The good new is that these are all well understood and documented.

When we define a subsystem to z/OS we apply the details to the IEFSSNxx PARMLIB member.  These entries are used by z/OS during IPL processing to build the subsystem vector table, which is a chain of control blocks, one for each formal MVS subsystem.

Each entry in the vector table is a SSCVT control block (SSCT) and as well as names and chaining pointers, also includes a couple of “user” fields.  When we define DB2 in IEFSSNxx, the entries look like this:


The INITRTN (DSN3INI) is driven at IPL (or SETSSI ADD) to do any setup initialisation.  In the case of DB2 one of the things that it does is build the ERLY control block and hang this off the first of the SSCT user fields.  So now we know why the contents of the SDSNLINK are usually referred to as ERLY-code.

Part of the DSN3INI population/build actions for the ERLY include saving the configuration options (cf INITPARM) and loading additional modules.  This means that the parms can all be found recorded in the ERLY.

Note also that ERLY is the stepping off/anchor point for all of DB2’s control blocks that support it’s operation.  As an example, the SCOM (which exists in the MSTR address space) is chained from the ERLY once it’s created (at subsystem startup).

DB2 Subsystems

Figure 1 – Control Block Chaining

It’s worth noting that MQ on z/OS is largely based on DB2 for z/OS.  As a result it also has an ERLY (same ID and eyecatcher) and SCOM pointer.  To differentiate between MQ subsystems and DB2 ones, check that the ERLY interface module name is DSN3EPX (as in INITPARM in the IEFSSNxx entry) rather than CSQ3EPX for MQ.

Details of each of these control blocks can be found in:


Some Code

The following is some example Rexx code that walks these control blocks to report all of the DB2 subsystems defined on an LPAR and whether they are active or not:


« »

Tag Archives