Mechanism for monitoring CICS storage fragmentation

We have assessed this requirement. We have no current plans for this to be implemented and so this requirement is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

Possibly enhancements in the arena of elastic scale implementation could help here. This will be discussed at the CAF.

It's possible that we may be able to develop our own tooling by employing the EXEC CICS EXTRACT STATISTICS SPI command. We'll have a look at that, although our preference these days is to attempt to decrease the volume of custom code we have, not add to it. As you are aware our environment does meet the description of being "quite dynamic" so our primary desire for this facility is to enable us to respond to developing situations quickly (perhaps by rerouting workload to other regions), before they have an opportunity to cause outages.

Well, the Storage Manager statistics do indeed provide the necessary information in order to assess the degree of storage fragmentation in real time. Not only is this data written to SMF on a periodic basis it is also available via the EXEC CICS EXTRACT STATISTICS SPI command, so you could write your own analysis program (this is what the DFH0STAT sample program uses) and this data can also be accessed in CICSPlex SM.

  I think I ought to add a cautionary note with regard to reacting to what a single snapshot of the Storage Manager metrics might be able to tell you due to the very dynamic nature how CICS can manage the dynamic storage areas. Using this data in real time one really needs to build up a picture of how the storage area extents and hence the largest free area metric are being used; any pressure on one DSA may then cause program compression to occur or a free extent to be moved from one DSA to another, in each of these cases the largest free area metric and therefore one's interpretation of how fragmented a DSA has become could dramatically change from one moment to the next. So I would recommend a more historical view point would allow one to make a more measured decision, that's not to say that a more reactive method might be worthwhile, but one just needs to be slightly cautious on the potential reaction one might take.

Similarly, for MVS storage as I mentioned earlier z/OS RMF Monitor I provides the VSTOR Virtual Storage Activity report in which the private area summary section of the report provides information on the largest free block available within the region's storage allocation. This type of storage is only available with the Monitor I post-processor, if something more real time is required, say on Monitor III then that really needs to be a z/OS requirement.

Is this sufficient ?

Sorry for the delay in responding, I've been out ill.
What I'm asking for is a way to assess the degree of storage fragmentation in real time, or near real time, so that we can be equipped to make decisions with regard to whether or not a given CICS region should be restarted or can be considered "safe" to remain up for another week. The impetus behind the request comes from business pressure to move closer to 24/7 operation. Using the existing metrics that are recorded in CICS statistics might provide the information but gaining access to the data in (near) real time is somewhat cumbersome. Ideally, the requested information would also be available to CPSM so that it could be used to trigger alerts, or considered in routing decisions as well.
Thanks,
Robert

The CICS Storage Manager statistics already provides the ability to be able determine to what extent storage fragmentation may have occurred. For each Dynamic Storage Area (DSA) the largest free area metric is maintained and using this value in conjunction with the available free DSA storage, this could be either by allocating a new DSA extent or by stealing an unused free extent from another DSA, will give you an indication of the storage fragmentation. e.g. if there are no free extents available then the largest free area indicates the largest storage area available to satisfy any GETMAIN request. This information is reported by both the CICS Statistics Utility Program, DFHSTUP, and the CICS Statistics Sample Program, DFH0STAT.

Similarly, for MVS storage (aka OSCORE) z/OS RMF Monitor I provides the VSTOR Virtual Storage Activity report in which the private area summary section of the report provides information on the largest free block available within the region's storage allocation. If this is a relatively small size compared to the total amount of free storage available then that is an indication that storage fragmentation has occurred.


Please let us know your comments on the above.