As some of us older folks may remember, OS/390 1.10 introduced 64-bit addressing to the mainframe, vastly expanding on previous the 2G address space limit. "The bar," as it's often referred to, is the 4G line. The memory above the 4G line is available for data, but at this time processors cannot execute instructions there.
IBM's CICS support spent several years trying to decide if they would support storage above the line. Then, after a statement of direction, CICS Transaction Server 3.2 introduced some limited support. Thus, the new release unveiled the grande dynamic storage area (GDSA).
As the G denotes, GDSA lives above the 4G bar. However, it plays by a few different rules. First, the maximum size of the GDSA is not specified in the CICS system initialization table (SIT). Instead, GDSA's size is defined by the MEMLIMIT applied by the operating system when CICS starts. The value for MEMLIMIT can come from several different places: CICS JCL, the SMFPRMxx member in SYS1.PARMLIB or SMF exit IEFUSI.
IBM stresses picking a good MEMLIMIT, because it generally can't be changed without an IPL or bouncing CICS. Fortunately, because the origin of the value can be a point of confusion, CICS helpfully includes the applied MEMLIMIT value in the DSA statistics records. IBM recommends a minimum MEMLIMIT of 2G.
Like other DSAs, CICS does not reserve GDSA in a phantom subpool that makes it unavailable to other programs. Instead, CICS gets the storage as needed. According to a dump I looked at, CICS allocates GDSA in 2G extents.
Short-on-storage (SOS) works a little differently, too. CICS considers GDSA SOS when the allocated storage reaches 90% of MEMLIMIT. The remaining 10% is considered the DSA cushion. As with other DSAs, the SOS condition is relieved when tasks end and storage becomes free.
In CICS/TS 3.2, CICS DSA (GCDSA) is the only DSA t...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
ype available above the bar. The only subpool available is PGCSDB, which the program manager domain uses to store channel container segments. A quick look at the CICS/TS 4.1 information center shows IBM added two other subpools for CPSM and the CPSM Web User Interface (WUI).
GDSA statistics
It wouldn't be CICS if there weren't statistics for the new DSA. The storage manager global statistics added these fields among others.
SMSGETSTO SIZE The amount of storage requested when CICS issues an IARV64 macro to get memory above the bar. I assume this value doesn't change but is used instead for incrementally acquiring GDSA as needed.
SMSASACTIVE Storage available above the bar
SMSGDSAACTIVE Current amount of storage in use above the bar
SMSMEMLIMIT The MEMLIMIT value set by the system for CICS. This field will be "NOLIMIT" if a limit isn't imposed.
CICS provides the GDSA cushion size, although you can calculate that based on the 90% in use rule with the value in SMSMEMLIMIT. Note that, since storage above the bar requires a 64-bit address, the values in the table above are 8-byte integers instead of the traditional 4.
There will also be a DSA statistic record for GDSA containing the same information as for the other DSAs. It's important to note, however, that the size values are in megabytes. Thus, a 4G value will actually be 4096 in the record.
As mentioned above, storage above the line requires a 64-bit address, which I'm sure the vast majority of CICS system code isn't prepared to handle. IBM solved this problem by adding the S2SR gate to the storage manager (SM) domain. S2SR has two functions -- one to copy data from below the bar to above and another to do the opposite.
While this is a simple solution to the problem, it does raise a couple of other questions. First, it reveals a potential performance hit each time a transaction manipulates channels and containers. This becomes especially important in CICS' implementation of Web services that uses those facilities heavily. Second, while storage above the bar seems limitless, the storage below is not. I can foresee a situation where CICS goes SOS below the bar because there are too many transactions trying to fetch large objects out of GDSA at once.
From the CICS/TS 3.2 and 4.1 documentation, it seems CICS is taking some slow steps into exploiting above-the-bar memory. Perhaps in the future other memory-intensive facilities such as temporary storage will be tossed up there too. You might also make a case for moving nearly all system blocks above the bar, which would free up storage below the bar and put them out of reach of traditional CICS application programs. There is also the interesting notion of "shared memory objects," which would seem to be a very cheap way to share data across address spaces without using Common System Area.
Unfortunately, so far the support is geared for CICS' use and there's no indication when or if the application programming interface will be extended to 64-bit addressing. But the storage is there, and if you can figure out how to use the IARV64 macro you may write a program to get some of that storage for yourself.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
