In CICS TS 3.2, customers can now use “above the bar” storage. Remember when we became so excited about above the line storage and being able to use more than 16-bit storage? At the time it seemed we’d never use all of it or need more. Well, just when you thought you’d hit the limit, here comes above the bar storage. For the most part, this storage is used by the channel/containers that are recently available, since some of these containers can be extremely large.
The new parameter in CICS TS 3.2 isn’t really “in” CICS but in the storage allocated by the region via the MEMLIMIT parameter passed to z/OS. Normally, customers would code a REG parameter in their execution JCL to create an address space size adequate to carve out the Dynamic Storage Area (DSA) below the line and Extended DSA (EDSA) above the line. CICS then dynamically allocates and frees storage as needed while the region is running. Remember, customers used to have to specify values for each one of these DSAs based on what they thought this particular region would require. That got tricky, since requirements fluctuated and a sudden spike in activity would cause Short On Storage (SOS) conditions. Performance and storage requirements were a constant struggle. Then, CICS introduced the ability to specify a global amount of DSA and EDSA. The System Initialization Table (SIT) gave you the ability to specify DSASIZE= and EDSASIZE= so you could give CICS a “chunk” of storage and CICS would then manage it for you. As one of the DSAs needed more storage, an additional “extent” was allocated to it. If storage in a DSA became unused for some period of time, an extent was freed from that DSA so it could become available to another DSA in that category. Storage allocation became much easier to manage since CICS was doing it for you.
Of course, with the introduction of containers in CICS, it became inevitable that more storage requirements were going to be needed. COMMAREAs were inadequate to hold the amount of data required for these applications.
GSA Storage Areas
The introduction of the GSA included four new GDSAs as seen in the documentation. Only one (GCDSA) is used for container data; we can only imagine that the additional DSAs will be used in the future for new functions. While none of the documentation available is specific about what the “G” stands for, one contact in Hursley has revealed that it stands for Grande, or Spanish for Grand. It appears this term was originally introduced by Bob Rogers when he was involved in developing the 64-bit architecture and instruction set. When Hursley implemented GDSA support, they used the same naming convention.
The new DSAs are created based on the value you specify with MEMLIMIT, either in SMFPRMxx within SYS1.PARMLIB or on the MEMLIMIT parameter in the EXEC statement of the region JCL. Once specified, the value of the parameter can’t be changed on a running system like the other DSA values below the bar.
In GDSA storage, CICS keeps track of the total amount of above-bar storage in use for the region’s address space and displays an SOS condition when 90 percent of MEMLIMIT is in use. The storage cushion is considered to be 5 percent of MEMLIMIT and CICS continues to allocate more GDSA storage until the logical CICS GDSA limit (95 percent of MEMLIMIT) is reached. As has always been the case when storage allocation becomes a problem, CICS issues appropriate messages and takes steps to start limiting new work to try and keep enough storage to service work already in progress. New MEMLIMITS can be introduced on the next start of the CICS region by altering the value in the JCL. As an added protection, CICS prevents any transaction from obtaining more than 10 percent of MEMLIMIT above-the-bar storage. When using GSA storage for containers, the actual data is stored above the bar but is moved below the bar by CICS whenever the data is needed for an operation and then moved above the bar whenever the operation is complete. Since the data is processed below the bar (in the ECDSA), you should remember that very large container sizes could affect the storage required by your DSALIM/EDSALIM values.
Size Recommendations
What value should you use for MEMLIMIT? IBM cautions that you should carefully monitor and size this parameter but: “There is no particular recommended value for MEMLIMIT in SMFPRMxx.
It very much depends on what an installation is doing so there is no "one size fits all.’"
As always, it provides a tuning opportunity for customers, and so it appears that as we get used to setting a value and doing proper monitoring, it will become more apparent what value is appropriate in each installation.
Summary
Hopefully, this has provided some insight into the new feature of storage allocation above the bar. As additional versions are announced by IBM, I’m sure there will be many opportunities to use this new feature.
