TS0028E in Mainframe Application Tuner Log After DB2 Upgrade
search cancel

TS0028E in Mainframe Application Tuner Log After DB2 Upgrade


Article ID: 45200


Updated On:


Mainframe Application Tuner


There was a ST0028E message error trying to start-up the MAT STC after upgrading the DB2 version.  

What does this mean, and what can I do to resolve it?




Component: MATUNE



The full message that one would see in the Mainframe Application Tuner (MAT) STC log is:

TS0028E CA MAT Synchronous Data Gatherer Target location is incorrect or has changed. MATUN50 START 

The message TS0028E is indicating a change has occurred and that can because of changes with DB2 or MAT (PTFs).  It's the actual lack of DB2 data gathering that would indicate that it really is an error.  So if this message is occurring AND DB2 monitors are not capturing DB2 data then this is an error that needs to be resolved.

It is noticed that after the DB2 customizations they are receiving:

With this value "DB2HVEXT=DB2E1" we get the ACTIVE message. 

If you use DB2E2 or DB2E3 we get the INACTIVE message (where DB2E3 is the default).

For DB2 we hook two different places in DB2 modules.  One DB2E1 is for general SQL only, DB2E2 is for COMMIT only and DB2E3 says to hook both.  When we implant our hook, we look at the hooking location to see it that location matches what we expect it to contain.  If it isn’t what we expect it to be then we won’t hook.  The result of that could be this TS0028E message.  It was either already hooked and has moved, or it hasn’t been hooked before by us, but for some reason it doesn’t contain what we are expecting it to, so some other product may have hooked it or the DB2 region may have come down and come back up and we had locations for the commit exits with the recycle of the DB2 region causing a change in memory locations. 

A specific resolution for a MAT case was that the sequence of starting the MAT server implants the DB2E1 intercept.  Manually stopping it via the stop command does stop data collection, but it doesn't remove the intercept.  We don't remove them.  Then issuing a start command for starting DB2E3 in DB2s DSNB subsystem will see that the intercept is still physically there and it will issue TS0028E.  The two monitors I see here are collecting intercepted data.  If anything, we might try to make the message more accurate when we start working on MAT V12, but this isn't a bug.

Initially, make sure one has "DB2HVEXT=DB2E1".