good practise to use CSA limit in VTAM
Tommy Tsui
One of IBM expert tell our shop to setup the CSA limit =0 in VTAM, but we
found IST561I STORAGE UNAVAILABLE: CRA4 BUFFER POOL problem when one of mq
server abnormal connect/reconnect to our host system. As we set the CSA
limit to 0 therefore VTAM use up all MVS ECSA. All commands cannot be
issued includes VTAM and MVS command. We IPL the LPAR finally. Is it a good
practise to set the CSA limit to 0. Anyone can share ?
Any help will be appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
David Stephens
I think you've already found out that setting the CSA limit to zero in
VTAM isn't a great idea. I'm always hesitant to set storage limits on
any subsystem to zero (or no limit) - I've had a couple of similar
problems over the years.
David Stephens
Lead Systems Programmer
d...@longpelaexpertise.com.au
www.longpelaexpertise.com.au
<http://www.longpelaexpertise.com.au/images/logo.gif>
Ph. 0404 757 821 (from Australia)
(Longpela Expertise Logo)
Longpela Expertise - System z Mainframe Consultants
Read new expert Mainframe articles every quarter in our LongEx Mainframe
Quarterly <http://www.longpelaexpertise.com.au/ezine>
Mark Zelden
outage it's usually easier or just as easy to IPL then recycle VTAM and
everything that needs it. So one way or another you're probably looking
at an IPL when VTAM crashes.
The problem with 0 is other subsystems that may crash or may not be
able to be brought down cleanly once you do run out of (E)CSA.
So if you want to micro-manage, you can set it to IEASYSxx defined
ECSA minus some reserved amount. Obviously setting it to 0 is a
"set it and forget it" setting.
I haven't been the one responsible for VTAM and TCP/IP in a while now,
but I usually have set CSA24 to no limit and CSALIMIT to about 80%
of IEASYSxx ECSA.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Chris Mason
Your analysis of this problem is illogical and thus may have misled both
yourself and the following contributors - even if one of them appears literally
to be prejudiced.
Based on message IST561I, there may be no need to touch your VTAM
CSALIMIT=0 or CSA24=0 start options.
Message IST561I is very well known[1] normally to be an indication that you
have not tuned your VTAM buffer pool values adequately. It is *not*
necessarily associated with
a) reaching a limit of storage allocated to VTAM
b) an indication that VTAM has/will use up all storage allocated to VTAM
If you search the z/OS Communications Server SNA Network Implementation
Guide for message IST561I, you will find it mentioned in the following extract:
<quote>
- Tune the expansion increments (xpanno) and expansion points (xpanpt) to
keep CPU overhead from dynamic buffering low.
-- Expansion and contraction of buffer pools increase the amount of real
storage that VTAM requires. If the buffer pools are continually expanding and
contracting, you should change the values specified for xpanno and xpanpt.
You can determine what values to specify by monitoring the output of the
DISPLAY BFRUSE operator command or the SMS buffer trace and by
modifying the values for xpanno and xpanpt accordingly.
-- If the expansion point is set too small, VTAM might not be able to expand
the buffer pool fast enough if there is a rapid demand for buffers. Setting the
expansion point too small also causes the buffer pool to contract frequently.
Message IST561I might indicate that storage is temporarily unavailable due to
this rapid demand. Adjust the xpanpt and xpanno values to eliminate this
problem.
The expansion point for I/O buffers should be larger than the largest single
request for buffers. Following are examples of the largest single request:
-- MAXBFRU allocation
-- NetView session monitor trace buffer size
-- JES/NJE TPBFSIZ
</quote>
Note the "***temporarily*** unavailable". If you understand how the dynamic
use of VTAM buffers works, you will appreciate that you need to acquire more
buffers when an expansion is needed or initiate the expansion when more
buffers are still available or both. This will deal with a peak in the demand for
buffers. The trick is to ensure that the asynchronous process responsible for
acquiring additional buffers keeps ahead of the mainline process which needs
to use the buffers.
Perhaps you can arrange to post DISPLAY NET,BFRUSE,BUFFER=CRA4 at the
time of preferably the first appearance of the IST561I message. Also post any
messages produced at the same time as the IST561I message together with
the IST561I message itself. And, for confirmation, post your current CRA4BUF
start option. Perhaps you have some automation package which can ensure
that the DISPLAY command follows rapidly on the appearance of the message.
Are you sure - quite independently of the appearance of message IST561I -
that VTAM has used up all MVS CSA? What is the proof of that? You could
start with posting D NET,BFRUSE output.
It may be some other component in your system which is using up all your
CSA and then preventing entry of commands.
What measures have you taken to monitor VTAM buffer usage - and ensure,
of course, that you have set sensible values? Regular use of the D
NET,BFRUSE command is needed.
I took a look at the CRA4 values shown in output from the 12 production
systems from the customer I assist from time to time and for whom I set up a
buffer pool initial values with a monitoring scheme. None of these CSA4 values
showed more than 28 buffers were used over many weeks. The values lay
between 19 and 28 for one set of systems and 11 to 14 for another set.
However, usage will depend on your applications. If you had done your
research on what CRA4 buffers are for you will see that VTAM is a bit vague
and describes the use as "scheduling and error recovery".
FWIW, my analysis of the customer's situation is to recommend setting the
following for the CRA4BUF start option in all production systems:
CRA4BUF=(20,,0,,20,10) CRA4 buffers
Chris Mason
[1] I'm amazed that you have not recalled this from your VTAM education. It
was a cornerstone of the presentation I used to give on how to manage VTAM
buffer pools.
Incidentally I guess the same goes for the following contributors. Perhaps
there will be a relevant comment by the time I post this!
On Fri, 8 Jan 2010 00:39:38 +0000, Tommy Tsui <tomm...@GMAIL.COM>
wrote:
>Hi all,
>
>One of IBM expert tell our shop to setup the CSA limit =0 in VTAM, but we
>found IST561I STORAGE UNAVAILABLE: CRA4 BUFFER POOL problem when
one of mq
>server abnormal connect/reconnect to our host system. As we set the CSA
>limit to 0 therefore VTAM use up all MVS ECSA. All commands cannot be
>issued includes VTAM and MVS command. We IPL the LPAR finally. Is it a good
>practise to set the CSA limit to 0. Anyone can share ?
>
>
>Any help will be appreciated.
----------------------------------------------------------------------
Chris Mason
Take a look at the explanation of message IST561I. This is ***not*** a
VTAM "outage". It is VTAM business-as-usual - although something dependent
on VTAM may show distress and may break in a way which needs operator
intervention in order to recover. IST561I is ***not*** - by itself going to
require either a VTAM restart or an IPL.
Chris Mason