Understanding what is happening under the covers with TDW

When you are starting up historical data collection for TDW there are several things that happen under the covers that you may need to be aware of. 

Here I show an example of starting history collection for z/OS Common Storage (CSA) utilization.  In this example we start by specifying the agent (in this example z/OS) and the attribute group to collect (meaning the table of information to gather).  You will then specify the collection interval, and how often the data is to be sent to the Tivoli data warehouse (TDW).  You then click on the distribution tab and select one or more managed systems to collect data from.  When you click Apply, collection should begin and the icon to the left of the collection definition should turn green. 

Once the collection definition is distributed, collection should be active and you should see a message in the RKLVLOG of the TEMA (meaning the agent address space).  You should see a reference to the starting of a UADVISOR for the table you are collecting (in this example UADVISOR_KM5_COMSTOR).   At this point collection should begin, assuming all the other required infrastructure is in place and operational. 

To validate that collection is occuring at the TEMA level, there are some useful commands.  One command to try is   /F taskname, KPDCMD QUERY CONNECT  (the taskname would be the address space where the TEMA is running).  This command will show the status of the various tables that could be collected by the agent, and how much data has been collected.  The information will appear in the RKPDLOG output for the TEMA task (see example below):

QUERY CONNECT



Appl  Table     Active  Group
Name  Name      Records Name      Active Dataset Name
-------- ---------- -------- -------- ---------------------------
KM5   ASCPUUTIL 31019   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   ASCSOWN       0   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   ASREALSTOR    0   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   ASRESRC2      0   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   ASSUMRY       0   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   ASVIRTSTOR    0   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   BPXPRM2       0   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   CHNPATHS      0   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2
KM5   COMSTOR      28   LPARDATA OMEG.OMXE510.ADCD.RKM5LPR2

Note that data is being collected for the COMSTOR table (as indicated by the active record count).  The next step in the process is to understand what is happening at the TDW and DB2 level.  We will look at examples of this in later posts on this topic.