I am running CICS/TS 1.3 and have noticed that I?m getting a lot of SOS messages under 16 meg. "DFHSM0131 PAR3 CICS is under stress (short on storage below 16 meg."I have coded in the DSALIMIT =9M. But, when I do a CEMT I SYS and try to increase the size of DSALIMIT over 9M, it will not accept it and gives me an error. If I try to increase it in the SYSIN, then it defaults to 5M. Is the 9M the maximum I can code? How can I set it to 10M.? What other parameters can I adjust to alleviate the SOS message?
The maximum value for DSALIMIT will vary somewhat from one z/OS system to another. It is limited by the maximum MVS Private area applicable to your z/OS system. You can execute the CICS sample STAT transaction requesting a Storage Manager report to give you a useful report on both the usage of storage by CICS, and the MVS storage constraints that apply to your z/OS system. I suspect, with DSALIM=9M, you are probably very close to the maximum value for DSALIM in your environment. The STAT report will identify the amount by which you could increase your DSALIM value, shown as "Private Area storage available below 16Mb." To increase your DSALIM value by more than this amount will require your MVS systems programmer to increase the size of the maximum private area below 16Mb by reducing the virtual storage reserved for the CSA and SQA below the 16 Mb line. Depending on the other workload running in your z/OS system, he/she may or may not be able to accommodate your request. A CICS Short on Storage (SOS) condition can be an indication of some other performance related problem. It can simply reflect the inability to process the number of transactions concurrently that may be requested during peaks in demand. If you are using an MRO configuration with one or more Terminal Owning Regions (TORs) and a number of Application Owning Regions (AORs), then the type of region in which the SOS condition occurs will affect the approach you use to address it. In a TOR, or a stand-alone CICS region, the primary control mechanisms are the MXT, or max task CICS initialization parameter which can be dynamically modified using the CEMT transaction, and the MAXACTIVE limit that you can chose to impose on the set of transactions that you have associated with a particular RDO TRANCLASS name. It is generally more efficient to adjust MXT to a value that is small enough that during periods of peak demand there is sufficient memory to process that number of transactions concurrently without encountering any storage stress conditions. CICS will automatically queue any additional tasks for execution until one or more of the currently executing tasks completes. A CICS SOS condition in an AOR or a stand-alone CICS region may reflect a contention for an application related resource not directly related to virtual storage management, such as logical or I/O related contention for database records that causes transactions to complete more slowly than when this contention is not present. If you are able to associate occurrence of SOS conditions with the execution of particular transactions, either because they may induce some type of contention or because they are simply very resource intensive, these transactions would be good candidates to associate with one or more RDO TRANCLASS definitions. This would limit the number of these transactions that will be permitted to execute concurrently via the MAXACTIVE option in the TRANCLASS definition. You can impose the MAXACTIVE limitation on transactions associated with a TRANCLASS in either the AOR or the TOR. The better approach for a particular situation will depend on your particular applications and environment.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our [email protected]/search390>discussion forums.