Thanks Sam. I had read the Redbook (sort of), but hadn't picked up on the rather important part: -
"The requested maximum buffer size is preallocated in SMF virtual storage. The buffer is dynamically managed such that actual storage used is maintained in a chained queue. As the buffer empties, chain elements are made available for use again. Page release processing releases auxiliary storage used to back the buffer storage." This does make me breathe a lot easier. Thanks again. Vince -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Knutson, Sam Sent: 07 February 2006 22:36 To: [email protected] Subject: Re: SMFLIMS & BUFSIZEMAX, BUFUSEWARN Hi Vince, Not at all! SMF Buffer Management in z/OS R6 and beyond is a big improvement over what existed before with or without the USERMOD in APAR OW56001. The details you seek are in the R6 Redbook in particular z/OS Version 1 Release 6 Implementation section 3.4.1 http://www.redbooks.ibm.com/abstracts/sg246377.html?Open 3.4 SMF buffer constraint relief SMF initially allocates 8 MB in its own high private storage for its buffers. These buffers are used to store records that are passed to SMF. SMF then asynchronously writes these records to the SMF data sets (SYS1.MANx) on DASD. If the data in the buffer is not copied to the SMF data sets or if data transfer from the buffers to the data set is slow, SMF continues writing the data it generates to its buffers. When the initial allocation of 8 MB storage is filled, SMF increases this buffer in 8 MB increments up to a maximum of 128 MB. If the buffers are allowed to be filled, it will result in a loss of SMF data. The message IEE986E is issued when the allocation of buffers in the SMF address space exceeds the warning level (default is 25%). As each additional allocation occurs, this message is redisplayed with an updated percentage value unit all of the buffer space is exhausted. When the buffer is 100% filled, message IEE979W is issued. SMF data is lost when: An SMF data set is not available and the maximum buffer allocation of 128 MB is full. SMF data is generated faster than additional SMF buffers can be obtained. APAR OW56001 provides relief by increasing the initial, incremental, and maximum buffer size limit and the warning level. The maximum buffer allowed with this APAR is 1024 MB. 3.4.1 Buffer constraint relief z/OS V1R6 provides parmlib support to allow customization of buffer sizing and the buffer usage warning level. The requested maximum buffer size is preallocated in SMF virtual storage. The buffer is dynamically managed such that actual storage used is maintained in a chained queue. As the buffer empties, chain elements are made available for use again. Page release processing releases auxiliary storage used to back the buffer storage. 3.4.2 New SMF parameters The following new SMF parameters have been added: BUFSIZMAX BUFUSEWARN MORE..... (see the Red Book) You can see my SMF parameters here http://bama.ua.edu/cgi-bin/wa?A2=ind0601&L=ibm-main&P=R35259&I=1 The key point you need to understand is that the virtual storage is preallocated. So allocate what you will need at peak utilization. The real pages will be released when not in use so you won't pay a penalty for paging in unused pages and you won't have a problem because the SMF address space cannot GETMAIN storage quickly enough to keep up with a spike. The consideration becomes do you have enough virtual storage available (EPVT) for what you specify and do you have enough real storage available (AFQ) at your peaks to satisfy the demand when all those virtual pages are temporarily backed by real pages. This enhancement has allowed us to eliminate all the data loss we still experienced on a recurring basis at midnight on some systems. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Vince Getgood Sent: Monday, February 06, 2006 11:02 AM To: [email protected] Subject: SMFLIMS & BUFSIZEMAX, BUFUSEWARN Hi all, We are currently running z/os 1.5, and have a usermod to change our SMF buffer sizes, increment size and maximum useage, as per APAR OW56001. We currently use an initial size of 128M and increment of 24M. We are in the process of migrating to 1.7, and I see that this APAR / usermod will not work on 1.7, but we have to use BUFSIZEMAX and BUFUSEWARN parameters in SMFPRMxx instead. >From what I've read in the zos 1.6 implementation red book, and 1.7 init. and tuning ref, It would appear that the inital SMF buffer size, and the increment size is 8M and CAN'T BE CHANGED. My question is, isn't that a step backwards? ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. ---------------------------------------------------------------------- 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 -------------------------------------- Dexia Bank disclaimer : http://www.dexia.be/maildisclaimer.htm -------------------------------------- ---------------------------------------------------------------------- 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
