No validations for accessing DB2 table by Top Secret checking

Document ID : KB000014708
Last Modified Date : 14/02/2018
Show Technical Document Details
Question:

We have a problem where we sometimes lose the CA Top Secret checking within CA Top Secret for DB2.

Using the CA Top Secret for DB2 trace utility (CADB2TRC), the first SQL run accesses a DB2 table. All the trace events are there. However, when running the same SQL a second time, the trace entries are very minimal. Only the DB2 plan is shown.

Why isn’t there a security event for attempted access to the DB2 table?

Environment:
z/OS
Answer:

When the ZPARM option 'CACHEDYN=YES' is active, DB2 is caching the allowed access from a dynamic SQL request. CA Top Secret doesn't control this caching, DB2 does. If CA Top Secret allows access to the DB2 table by a dynamic SQL request, then DB2 caches it and the security calls to CA Top Secret won't happen again until the cache is cleared.

The way to clear the cache is to either stop and restart DB2, or invalidate the cache by running the utility RUNSTATS.

Additional Information:

The CACHEDYN subsystem parameter and the RUNSTATS utility are documented on IBM’s website at the following links;

* CACHE DYNAMIC SQL field (CACHEDYN subsystem parameter)
https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/inst/src/tpc/db2z_ipf_cachedyn.html

* Sample RUNSTATS control statements (cf. 'Example 17')
https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/ugref/src/tpc/db2z_samplesrunstats.html