We're running CICS/TS V5.6.
Our CICS is expected to run out of 2G virtual storage in the near future.
Basically, the amount of programs used is large, so the size of the ERDSA reaches 800M.
As shown below, EDSALIM is 1300M and we uses almost all of EDSA storage.
We are planning to develop large-scale new businesses over the next two or three years. The size of the ECDSA storage will be larger and larger.
=======================================================
Current EDSA limit : 1300M
Peak EDSA total : 1233M
Peak DSA size : ECDSA 102400K
EUDSA 358400K
ERDSA 799744K
ERDSA
-----
Program removed by compression : 0
Reclaims from Not In Use queue : 263730K
Programs loaded but Not In Use : 41539
Amount of DSA occupied by Not In Use program : 748001K
=======================================================
To overcome the storage problem, we have considered several ways.
1. Increase EDSALIM
Every time a program compiled from COBOL V5 is loaded into CICS, it generates a WSA of 4K per program and allocates it to subpool 229 Key 0. As a result, our LSQA/SWA/SP229/SP230 area is increasing by 2-3 MB per month. In order to avoid 878 abend, we rather have to reduce EDSALIM.
2. Add more CICS AORs for ERDSA
We already have about 80 CICS regions running within this CICSPlex. And since many online transactions are carried out through the same framework, most programs are used in common. As we have tested, ECDSA usage does not decrease significantly even if transactions are dispersed by adding regions.
3. Add more CICS AORs for EUDSA
Our system processes about 8000 to 9000 tps at the current peak.
We are going to select transactions with high data volume and very high EUDSA usage and perform them in a separate region through transaction grouping. This may prevent the instantaneous large-scale use of EUDSA. However, it is not known how much it will help resolve the shortage of EDSA in CICS, where the size of ECDSA is basically 800MB or larger.
=====================================================
The customer's request is this.
It is asking for CICS region to implement ways to take action on its own or manually before a problem situation occurs in the system, such as short-on-storage. There is room for a lot of storage within the CICS region architecturally. But that's true if CICS keeps used areas free and reusable by itself or manually. But this is not available until CICS reaches Storage Norify request.
In the early days of CICS, they would have considered 2G storage shortage is a special situation and created a logic to compress the program when faced with the problem such as short-on-storage. However, we need to reuse already used areas at any time because 878 abend or SOS can occur without any special problems.
We are not in short of storage yet. However, we will continue to make efforts to distribute workload to clone AOR to prevent storage shortages that are bound to occur in the future. Nevertheless, there are still limitations of 2GB, and storage must be reused to effectively utilize the insufficient areas. Therefore, I would like to request a function to secure storage through program compress in advance before reaching short-on-storage.
CICS Development: t is not clear that the desire for a compress-on-demand capability would be useful for this scenario. The current behaviour is to load a program, and then keep it resident unless USAGE(TRANSIENT) is specified. The main scenario where a forced program compression would be of assistance is if many large programs have been loaded into CICS and then are subsequently never used. But that scenario is what USAGE(TRANSIENT) was designed for, in which case can this existing capability be used?
A forced program compression would mean a performance hit when those programs that were thrown away were next used, and such an instantaneous spike in CPU / response time would be unpredictable, but related to the number of programs needing a reload.
Firstly program compression would only be useful if it resulted in removing a significant number of large programs to make a significant impact on the 800M.
Secondly storage fragmentation may mean that the goal of shrinking ERDSA would not be achieved. The request is to allow program compression in order to reduce ERDSA, but unloading programs that will be subsequently reloaded will create storage fragmentation. Where programs aren't changing often, this fragmentation may not be too noticeable. Working on the assumption that programs only ever increase in size, however, you will end up with holes in ERDSA where the larger programs will no longer fit. The net result is likely to be that a forced program compression will take the performance hit, but if an ERDSA extent contains even just one program, then that extent cannot be freed, and hence the ERDSA would never shrink, or maybe by an extent or two.
For these reasons the Idea is being rejected.