How much CICS storage does each DBC USER thread consume?
Article ID: 14321
Updated On:
Products
Issue/Introduction
Client is looking at CICS Memory involved with CA Datacom/DB CICS interfaceand some memory tuning information.
What is the amount that each DBCVTPR USER= costs?
Environment
Resolution
The size of the DBCVTPR module has no relationship to the number of allocated threads.
The portion of storage for each additional thread is 8K above the line in the CICS address space.
Additional Information
Other useful comments:
Each thread consumes two different types of storage.
- A tiny portion in the CICS address space which is allocated above the line
and
- another portion in the "data space" on the MUF side where the size is almost of no consequence.
I looked at the DBOC INQ=USERS stats provided. At the first glance, it appears over-allocated, but since it is only for a 24-hour cycle, I would be hesitant to say it is. I would like to have access to an entire year’s stats to see whether it ever uses all the 35 threads or not. If the thread count is reduced by any significant number and during some month-end, year-end or some other special processing heavy volume occasion all the threads get used and the system gets backed up, then there would be some risk of "short on storage" events, where the accumulated but unassigned tasks would tie up CICS resources and in the worst case it could freeze the region. As it is very well known, a few other factors such as how much USER, CICS, DSA storage in various areas above and below the line is available at startup time, the max task, etc.
Additionally, if none of the sever conditions described above happens, the best case would be that queuing of the tasks in the DBC address space would require special processing which would burn quite a bit more CPU cycles than a normal request would.
So, I am in favor of tuning the system for efficient use of storage in CICS but would consider an entire year’s stats before I make a drastic reduction in the number of threads.
The other thing I would do is look at the "end of job" statistic in CICS and see whether the high-water marks for storage usage are anywhere close to the actual available storage, or have any "short “on storage events ever happened (which are serious tell-tell signs) then I would look for savings where it would pose the least amount of risk otherwise.
Looking at the other environmental DBC parameters,
- I like the fact that MAXURTS is a small number at 375 (some define it at 9999 unnecessarily and pay a big price in terms of CPU cycles);
- I would suggest PGMNAME=TASK if the program name is not needed for every request; that cuts down on CPU cycles depending on the average number of request per CICS task.
- I would do TRACE=(ON, 0100) instead of OFF; that is just a circular trace table in core but could be a valuable tool with negligible resource use.
- I like the fact that the option of SKPSYNC=YES is selected; that can provide a big savings depending on the type of workload.
- I would also select OPENAPI=YES to get a better throughput if I needed some. This can use a few of the remaining idle 25 threads in favor of a faster response and even the application does not need to be threadsafe; this is all about how efficiently we allow DBC to process requests.
- But the maximum number of open TCBs has to be considered carefully (please look up the IBM manual for setting MAXOPENTCBS, it has to be at least fifty percent larger than MXT ).
- The other consideration is whether this DBCVTPR is being used for just one CICS region or is it used in many CICS images with varying work load requirements. In the latter case I would customize one CVT for each CICS image depending on the need and the available resources.
To summarize, if we have access to an entire year’s stats and know for a fact the threads are underutilized, or are pressed for storage, by all means reduce the number of threads and monitor the thread use for extended periods of time to validate the proper settings.
Feedback
