> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of William Richardson > Sent: Friday, September 14, 2012 8:57 AM > To: [email protected] > Subject: Re: SMF Dataset CLOSE PENDING ISSUE > > General note ..... "Close Pending" status for an SMF dataset is > actually fairly normal but should NOT persist for very long. It > basically means that SMF is still writing data out to that physical > dataset but has "logically" reached the end of the file and is > collecting/targetting its current input data to the 'next' dataset > (which in this case there is none - which I suspect might have been the > source of the issue).
Interesting to know about CLOSE PENDING. But I don't understand the explanation because, in the past, I have had all my SMF data sets fill up. In that case, SMF started buffering "in memory" and the last used MAN data set was "DUMP REQUIRED". This was before I had CA-OPS/MVS issuing a command to start the STC which would dump the switched from MAN data set. It is also why I have a "spare" MAN data set already defined and EMPTY so that I can add a new one quickly. IIRC, I had to do this one time when SMF records were being created faster than they could be written to disk so every MAN data set filled up and I couldn't empty the fast enough. > > Second note ...... you really should have procedures in place on the > system to "dump" and CLEAR SMF datasets as soon they become FULL - you > should never really have SMF datasets that are in "dump required" > state. That's system data that has been collected and is just sitting > there not being used for its intended purpose. IF for some reason > there is no actual need for the data then just make sure to CLEAR the > datasets as they become FULL. I agree. I used to have an IEFU29 exit, but found it easier to use a CA-OPS/MVS rule to start the dump process. > > Third general thing ..... "Close Pending" is USUALLY an indication of a > thru-put performance iusse with SMF - that is, the data is being > collected as a FASTER rate than it is being physically written out to > the SMF dataset. In most cases there might be a data spike that causes > this sort of behavior instead of a sustained data rate issue; the other > possiblity to consider is an I/O (performance) issue with the physical > SMF dataset itself. I was thinking that a hardware RESERVE on the volume containing the MAN data set from a different z/OS system might cause this. I have converted most of the hardware RESERVEs into GRS global ENQs. > > Finally, as has already been noted .... if the problems persists then > contact IBM Service. > > Thanks, > Bill.... > z/OS Development and Service -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 • N. Richland Hills • TX 76010 (817) 255-3225 phone • [email protected] • www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
