No validations for accessing DB2 table by Top Secret checking
search cancel

No validations for accessing DB2 table by Top Secret checking


Article ID: 14708


Updated On:


Top Secret Top Secret - LDAP


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?




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)

* Sample RUNSTATS control statements (cf. 'Example 17')