Implementing Security › Using Resource Caching › Resource Cache Operation

Resource Cache Operation

Each terminal is allocated its own resource cache buffer. The size of the buffer is determined at start-up from the CICSCACHE facility option. Complex transactions that access many secured resources may require larger buffers. If the buffer becomes full during the life of the cache, it will be cleared to accommodate new entries. Earlier cached entries will be lost. In order to maintain the advantages of caching, the cache size selected must be appropriate to the applications in the region with that facility. When TASKLIFE caching is used, the cache is cleared at the start of each transaction. When SESSLIFE caching is used, the cache is cleared when the user signs off. SESSLIFE is maintained as far as possible during operation until new entries require clearance.

Cached resources are only checked for

• Resource class
• Resource name
• Access level

Additional restrictions are not checked for cached resources. For example:

• PRIVPGM
• LIB
• DAYS
• TIME
• CALENDAR
• TIMEREC

However, RLP restrictions will be checked on every check, if they were present when they entered the cache.

• Advantages of TASKLIFE caching
  • Cache size is smaller than for session life cache
  • If changes occur in a user's permission to a resource, they will be rechecked at each transaction
  • If restrictions are present on the permission, they will be rechecked at each transaction
• Advantages of SESSLIFE caching
  • Repeated access to a set of resources will remain in cache during the life of the end-user session, preventing the need to recheck
  • Significant reduction in Security File I/O, during run-time applications, especially with repeated complex transactions
• Disadvantages of TASKLIFE caching
  • Increased access to the security file may lead to performance degradation
• Disadvantages to SESSLIFE caching
  • Some restrictions on permissions will not be honored on subsequent accesses, after a resource has been cached.
  • Memory required for session cache is larger than for tasklife
  • Audit requirements may be compromised
• When CICSCACHE is set to AUDIT, then resource classes with the AUDIT attribute, individual resources in the AUDIT record, and users with the AUDIT attribute will be treated differently in cache than they would otherwise.
  • Audited resources will automatically be rechecked with each access regardless of caching.
  • Audited accesses will be logged in the ATF or SMF, according to your installation control option settings
  • When RDT or AUDIT record no longer require auditing, processing of cache returns to normal immediately
  • When a user is signed on, the AUDIT requirement is maintained until the user signs on again or is refreshed by the administrator

When CICSCACHE defaults to NOAUDIT, auditing occurs only on the first access to the resource during the life of the cache. Clearly, if session life caching is in place with NOAUDIT, it may be possible to miss auditable events during the life of the check.