Comments (5)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 ijmitch commented Permalink

Great stuff! I wondered if you'd seen the append on CICS-L - will you point the CICS-L folks over here?

2 MartinPacker commented Permalink

Thanks Ian. Yes, already done. Happy to continue the conversation there or here. (The first mention of CICS-L is a live link to where you can sign up for it or read the archive.)

3 MikeWood commented Permalink

Doesnt CICS provide some way of reporting how well the buffer pools are performing? <div>&nbsp;</div> DFSMSrmm also uses LSR buffer pools. Rather than do loads of performance checking and providing knobs to tweak I simply provided, what I thought at the time, was a big pool. From the rmm I&amp;C Guide .... <br /> "The LSR buffer pool is 800*data CISZ + 200*index CISZ. <br /> Assuming 10 240 for the control data set data CISZ and 2 048 for the control <br /> data set index CISZ, the value is 800*10 240+200*2 048=8.4 MB. If you use <br /> larger CI sizes, more buffer space is required. For example, if you use a 26K <br /> data CISZ, a 21.2 MB buffer size is required." <div>&nbsp;</div> What I also did was to add in code to obtain the VSAM statistics when needed. Some kind of SHOWCB if I remember - gives hit rates etc. <br /> We never externalized the information, but would be easy to do .... so, if it were cut as a SMF record it would be easy to report on benefits (if any) and lead to a way to provide customer options to tailor it .....

4 MartinPacker commented Permalink

Thanks Mike. Yes CICS Statistics Trace (SMF 110) has buffer pool effectiveness information. Generally that's more than good enough. It's if you want to try predicting the effect of increasing the buffer pool size that you need F61 etc. <div>&nbsp;</div> <div>&nbsp;</div> 21MB is a lot more than many customers have for CICS buffers. I think the sizing is based on 24-bit virtual memory constraints and hasn't been revised since 31-bit became commonplace. But I'm hoping some customer will post here, telling me they've got CICS pools in the hundreds of MB per region. Then we get into the fact that's per File-Owning-Region or whatever. So there's a multiplier. Unlike DB2, which has one set of pools for everyone to take advantage of. <div>&nbsp;</div> <div>&nbsp;</div> The approach of having a fixed buffer pool size is an interesting one. Then the burden is transferred to RMM to ensure each release reflects whatever the new reality is: Bigger file, cheaper memory etc. As a matter of interest do you use Deferred Write in RMM? I would suspect not as the writes probably need immediate hardening.

5 MikeWood commented Permalink

Martin, RMM uses some deferred write and some not. <br /> For example, app opens a tape data set, rmm writes the updated CDS records and forces VSAM to write out the buffers via WRTBFR. i.e kind of like a transaction basis. <br /> However, during "inventory management" rmm tries to maximise the benefit of deferred write, inluding things like sorting the updates in key order and making the updates in one go after making all decisions about what changes actually need to be made to the records. <br /> The benefit of such a change could very easily be seen via the VSAM statistics and the reduction in the I/O counts to the CDS.