CICS TS 3.2 became available at the end of June 2007. This release has many interesting features, including the first attempt to support data structures above the bar. Initially, the 64-bit support is for channel/container data that will be stored above the bar. Access to storage above the bar lets the CICS TS user store and access a significantly greater amount of virtual storage without limiting the amount of data to be stored in containers. However, this storage does require backing by real storage space when used; therefore, care must be taken not to overcommit the amount of real storage, thus causing the CICS TS system to degrade in performance because of increased paging. This article offers a general overview of CICS TS’ use of storage above the bar.
It’s now a requirement to allocate storage above the bar so CICS TS 3.2 can be initialized. If no storage is allocated or available above the bar, CICS TS 3.2 won’t come up and the system will send an error message. How much storage is recommended above the bar depends on each installation’s container data usage. However, IBM recommends a minimum allocation of 2GB for CICS TS 3.2. The storage above the bar is allocated via the MEMLIMIT parameter.
If the MEMLIMIT allocation is less than 2GB but greater than the EDSALIM, CICS will issue a warning message. However, if MEMLIMIT is set to a value lower than the EDSALIM, CICS won’t come up and the system will send an error message. CICS TS will dynamically allocate space above the bar only as required and doesn’t allocate space unless you’re going to use it. So, specifying a large value doesn’t necessarily affect performance unless you get a rogue transaction allocating container space in a loop. In that case, you could cause paging or page data set slot depletion, which could affect the rest of the system. Allocations occur in multiples of 1MB pages. The process used is similar to the way CICS TS works when dynamically allocating storage for the (E) DSA by using the DSALIM/ EDSALIM parameters. However, there’s no SIT parameter available to indicate the amount of storage available above the bar.
There are several ways you can allocate space above the bar to the CICS region, but a common method is to code the MEMLIMIT parameter in either the JCL JOB or EXEC card (see red arrow in Figure 1). In this case, the requested MEMLIMIT is an exaggerated amount and demonstrates that it doesn’t affect the CICS initialization. There’s one caveat that requires attention when the user doesn’t provide a MEMLIMIT size and REGION=0M is specified for the JCL region parameter. In this case, the system assumes NO LIMIT as the MEMSIZE. The allocated space also can be specified via the SMF MEMLIMIT parameter in SYS1. PARMLIB or controlled by the IEFUSI SMF exit.
There are several other methods available to allocate storage above the bar for an address space, but they’re beyond the scope of this article. Each installation will use the established criteria to allocate and control the amount of storage above the bar. Extensive use of storage above the bar will require an increase to the Page Data Set (PDS) allocations to support the z/OS Auxiliary Storage Manager (ASM). As this is a z/OS issue, you’ll have to coordinate with your z/OS systems programmer. Also, as stated previously, remember that you’ll also require real storage to support the increased virtual storage use by CICS TS for data stored above the bar.
CICS TS handles movement of the container data back and forth between the storage above and below the bar. When you create a container using the PUT command, CICS TS will store the data defined above the bar. Your application can’t access this data above the bar. When the application requires the data, such as via a GET command, CICS TS will move it below the bar for application access and processing. The user can issue the GET command using either the SET or FROM options so the application program can access the container. Although, theoretically, a user could access the data using the z/9 instruction set (e.g., LG and SAM64), CICS TS doesn’t support this option and doesn’t provide or save the high order word of the register contents except when an abend occurs. So, be careful leaving residual values in the high order portion of registers when using the 64-bit instructions.
The Storage Manager (SM) domain has been changed to support the 64-bit structure the channel container data uses. New fields have been added to the SM anchor block using 8-byte fields for addresses above the bar. Also, since the amount of storage that can be allocated above the bar is so large, many of the length fields also have been upgraded to 8-byte lengths. To control storage above the bar, SM uses the concept of dynamic storage areas; this is similar to the technique used to manage the storage allocated above and below the line. The new name for these areas above the bar is preceded by the letter “G” or Global Dynamic Storage Area (GDSA) vs. Dynamic Storage Area (DSA) for below the line storage and Extended Dynamic Storage Area (EDSA) for above the line storage.
There are four new GDSAs that can be seen in the documentation but only one (GCDSA) is used for container data. The actual data is stored above the bar and moved below the bar by CICS whenever the data is needed for an operation such as a GET and moved above the bar whenever a PUT is executed. The channel/container control block structure is still located in the ECDSA. Since the data is processed below the bar, you should remember that the excessive container sizes could affect the storage reserved by the DSALIM/EDSALIM parameter (e.g., such as going SOS). The four new GDSAs are:
• Grande/Global CICS Dynamic Storage Area (GCDSA)
• Grande/Global User Dynamic Storage Area (GUDSA)
• Grande/Global Shared CICS Dynamic Storage Area (GSCDSA)
• Grande/Global Shared User Dynamic Storage Area (GSUDSA).
It isn’t clear from the documentation whether the “G” stands for Grande, which can be translated to the word “big” in Spanish, or Global. These GDSAs may (or may not) be used in future releases as the Hursley CICS staff decides to place more information, such as control blocks, data and tables, above the bar. The actual GDSA names may vary, since IBM hasn’t formally announced these GDSAs nor mentioned their possible use.
The first two GDSAs are simple to understand; they allow the separation of USER and CICS areas. The availability of user-related storage above the bar would require the expansion of the GETMAIN command (or a new command) to acquire storage above the bar for user storage or it could be automatically attained by CICS for some type of user storage. The remaining two GDSAs are a little vague at this time. The “S” could represent shared storage that could be used as an extension of the transaction isolation feature or for shared areas that exceed the life of the task. However, we’ll have to wait until Hursley CICS staff implements the new support associated with 64 bits above the bar. There’s currently only one domain storage subpool in use called PGCSDB. This storage subpool is associated with the Program Domain (PD) and is used to hold the container data.
The new 64-bit support for CICS TS 3.2 required changes to the SM anchor block to accommodate the new 8-byte address structure. The 64-bit structures were added to the end of the anchor block (see Figure 2). In addition to the 64-bit addresses, the anchor block contains statistical information regarding when to indicate Short on Storage (SOS), the current amount of storage allocated and the MEMLIMIT specified. The MEMLIMIT reflected in Figure 2 (yellow arrow) is the same value requested in the MEMLIMIT parameter in the JCL seen in Figure 1. As mentioned, the 64-bit design includes the use of four new GDSAs, of which only one (GCDSA) is being used to support container data. Rather than altering the current control blocks such as the Page Pool Control Area (PPA), Page Allocation Map (PAM), or Page Pool Extent Control Area (PPX) to support larger addresses and lengths, the Hursley CICS staff decided to add new control blocks such as the GPPA, GPAM, and GPPX to provide the 64-bit support, reducing the complexity to implement the new structures. These new control blocks reside in the GCDSA.
MEMLIMIT can’t be altered during CICS execution. So, this requires that the availability of storage above the bar be closely monitored when this storage is used. A new MEMLIMIT allocation can be made when CICS is reinitialized. This is different from the way storage below the bar is handled because you can dynamically alter the EDSALIM/ DSALIM using CEMT as long as there’s sufficient z/OS storage available. The allocated storage above the bar is shared by all the GDSAs. An SOS above-the-bar condition is recognized when the total storage above the bar being used reaches 90 percent of the allocated MEMLIMIT. The storage cushion is equal to 5 percent of the allocated MEMLIMIT. CICS will use this 5 percent storage cushion to allocate storage to the GDSAs until 95 percent of the MEMLIMIT is reached. The remaining 5 percent will be used to service work already in progress. The system sends appropriate messages and CICS takes the necessary steps to limit new work and keep sufficient storage to service work already in progress. As an added control, CICS prevents any executing transaction from getting more than 10 percent of the allocated MEMLIMIT storage.
CICS TS 3.2 introduced an interesting change in the way the container data was stored. In CICS TS 3.1, the container data was stored in the ECDSA in 4K segments. Data that exceeded a certain size wasn’t stored contiguously in the ECDSA. Each 4K segment consisted of a 40-byte control area at the beginning of the control block followed by up to 4,056 bytes of data. Container data that exceeded 4,056 bytes required more than one data segment to store. CICS handled the blocking and deblocking internally so the user viewed a contiguous piece of data. The idea was to make better use of the storage available by reducing the need for large contiguous page space in the ECDSA. The trade-off was some CPU overhead.
Figure 3 shows the creation of a 100,000-byte container called SALARYINFO using a CECI transaction, and Figures 4 and 5 show how CICS divided the 100,000-byte container data into small 4,096 segments, of which only 4,056 bytes were used to store the container data. This process wasn’t necessary in CICS TS 3.2 due to the availability of virtual storage above the bar. In 3.2, the data is stored contiguously (see Figure 6).
There are many possible uses for storage above the bar that can be easily implemented by CICS without the need for user programming changes. The major advantage of moving certain areas above the bar is to make more storage available out of the (E) DSALIM for users that may be reaching the maximum storage available above/below the line or are planning to expand Web access and/or the use of Java. The disadvantages of the current approach are:
• No support to access data above the bar has been announced for high-level languages such as COBOL/LE.
• Extra CPU time is needed to move the data back and forth from above the bar to below the bar and vice versa. • As you increase the amount of virtual storage supported by CICS, more real storage and page data set space will be required.
Examples of possible uses for storage above the bar are:
• Temporary Storage Main (TSM): Many users have taken advantage of TSM for faster access to Temporary Storage (TS) data. Data in TSM works similarly as CICS has implemented container data above the bar. The TS data is stored in the ECDSA and moved back and forth to user storage as required. Support for TSM above the bar would require changes to the control block structure to accommodate the address and length fields from 4 to 8 bytes, if IBM decides to increase the record size to greater than 32K. As the amount of virtual storage above the bar is quite large, users who previously couldn’t use TSM because of the large quantities of above the line virtual storage required to support their system, would now be able to consider TSM using the storage above the bar. Auxiliary TS would still be required for recoverable TS queues.
• COMMAREA: This storage could be stored above the bar when a return to CICS with transaction id is specified. When the transaction is restarted, the data could then be moved below the bar for processing by the user program. Again, several control blocks would need to be changed to support the 8-byte addresses. As the length is limited to 32K, no changes to the length would be required.
• Trace Table: The trace table also could be moved above the bar, releasing the storage it currently occupies above the line. This also would provide the user with the capacity to significantly expand the size of the table for debugging some problems that would now require the use of the auxiliary trace on disk because of the amount of data required.
• Java: The placement of class cache and other JVM-related information above the bar also would help alleviate space in the EDSA.
There are probably many more uses for storage above the bar that can be easily implemented, including the capacity for the user to be able to acquire storage above the bar for application purposes. CICS could provide the means via a special command to move the data back and forth so that high-level languages that don’t support 64-bit addressing can use the data above the bar. This is the first significant change to the SM domain in many releases. It truly represents the next frontier in the exploration and exploitation of virtual storage for online CICS systems.
