This blog does not have the intention to go in to full detail on the differences but to show at a high level the similarities and differences between DB2 for LUW and DB2 for z/OS.
Let’s start with DB2 for LUW. Here below is a graphic overview of what could be a DB2 for LUW environment.
On one server one or multiple virtual machines (VM1-VMn) have been defined. On each of those VM one or multiple instances of DB2 for LUW can be defined. Each of those instances will have a set of configuration parameters defined, we find those in Database Manager configuration (DBM-config) there is only one of those per instance. Each instance also has a DB2diag, this is the diagnostic log file. The purpose of this log is primarily to troubleshoot the DB2 instance. Within one instance you can have one or multiple databases.
Such a database has its own set of configuration parameters. They can be found in the Database Configuration file. When working with DB2 for LUW, you will connect to a specific database in order to start working. Each database within the instance has its own meta data (catalog), its own IO areas (bufferpools) and its own logging, so none of these structures are shared with other databases on that instance.
Table spaces are files/containers that hold the data for one or more tables and/or their indexes.
When looking at DB2 for z/OS, some similarities are immediately obvious.
On one physical z-series machine, one or multiple Logical Partitions (LPAR) can be define. The logical partitions behave up to a level as if they were different machines all together. The comparison with the Virtual Machines on an LUW server can be made.
Within one LPAR one or multiple DB2 Subsystems (SSID) can be defined. Each subsystem has a set of parameters defined that controls its behavior, those parameters are called the DSNZPARM parameters. They have a similar function than the DBM configuration on a LUW instance, combine with the DB config on a LUW database.
One of the major differences is that DB2 for z/OS, has one set of meta data (catalog), one set of IO areas (bufferpools) and one set of log dataset per subsystem, rather than per database. A database in DB2 for z/OS is nothing more than a logical grouping of DB2 objects. In DB2 you connect to a DB2 subsystem, once you are connected to it, you can query any table (provided the correct security clearance), regardless of which database the table logically resides. Certain error messages , similar to DB2DIAG, can be found in the ssidMSTR, the master address space of the DB2 sub system. In DB2 for LUW the MSTR-address space would be considered one of the processes that run and make up DB2.
Tables are placed in (VSAM) files called table spaces. One table space can contain one or more tables, although there is a definite trend to place each table in its own table space. Each index is always placed in its separate file (index space).
IDUG content committee leader