Customer reports over 18,000 CICS transaction detail logger datasets retained, exhausting storage pool
Release: Component: SYSVW
Check the log stream definitions. Go to LGSTREAM in SYSVIEW, find the log stream in question (GSVX.CICSLOGR.TRAN), and issue an L line command next to it. This will show the log stream policy info… like this:
For the CICS transaction log stream, I would typically not recommend more than a retention period more than 7 days. The lower this number is, the less offload files the logger will keep around:
For the CICS transaction log stream, in a high volume environment, the offload data set size should be generous. For example a LS_SIZE of 20000 would mean each offload could hold 20000 4K blocks. Each SYSVIEW record compresses down to 1K, so doing a little math a LS_SIZE of 20000 would only hold 80000 CICS transaction records. I would bump this number way up if they have a low number specified here. 100000 to 500000 is more reasonable in a big environment. Note 500000 is a 2G file. This should drastically reduce the number of offload allocations they are seeing.
One last setting that might need reviewed is the STG_SIZE. This is the in memory and disk buffer. This allows the log stream to buffer records while offloads are occurring. You never want to make this number larger than LS_SIZE, but you can make it equal. I would not go above 100000 on this because it will raise real storage usage as well. Note 50000 will equate to about 200M real storage.
The log stream can have these attributes updated dynamically, but all connections must be dropped to the log stream before the changes take place. The old offloads will still hang around until the retention period expires them off. Sample job: