Tommy 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 <[email protected]> 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
