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)