Re: How SMFDUMP works?
Yes, we changed those dsnames recently... 2006/1/23, Imbriale, Donald (Exchange) [EMAIL PROTECTED]: It's possible the problem is with your IEFU29 exit. There's an item on IBMLink that mentioned this. Try starting SMF without the IEFU29 exit. When a switch from one of your SMF dump data sets occurs either because the data set is full or you manually switch it, see if the status of that data set changes to DUMP REQUIRED as expected. If it does, then you can take a look at your IEFU29 exit to see if there's a bug somewhere in there. Did you recently change the dsnames of your SMF dump data sets? Don Imbriale -- 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
Re: How SMFDUMP works?
If your IEFU29 exit is old, it may be expecting dsnames to be fewer characters (my guess would be 9). If the new dsnames are longer and the exit wasn't changed, then it is possible that you are overwriting storage in your exit. Check your IEFU29 exit to make sure the length of the fields that hold dsnames is long enough to support your new dsnames. Also, don't forget to try running without the exit to see if all is OK. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Víctor de la Fuente Sent: Wednesday, January 25, 2006 6:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Yes, we changed those dsnames recently... 2006/1/23, Imbriale, Donald (Exchange) [EMAIL PROTECTED]: It's possible the problem is with your IEFU29 exit. There's an item on IBMLink that mentioned this. Try starting SMF without the IEFU29 exit. When a switch from one of your SMF dump data sets occurs either because the data set is full or you manually switch it, see if the status of that data set changes to DUMP REQUIRED as expected. If it does, then you can take a look at your IEFU29 exit to see if there's a bug somewhere in there. Did you recently change the dsnames of your SMF dump data sets? Don Imbriale *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: How SMFDUMP works?
Yes, we are using it: MEMBER =3D SMFPRM1E MULCFUNC -- DEFAULT MEMLIMIT(0M) -- DEFAULT DDCONS(YES) -- DEFAULT LASTDS(MSG) -- DEFAULT NOBUFFS(MSG) -- DEFAULT SYNCVAL(00) -- DEFAULT INTVAL(30) -- DEFAULT DUMPABND(RETRY) -- DEFAULT SUBSYS(TSO,NOTYPE(16,19,90,99)) -- SYS SUBSYS(TSO,DETAIL) -- PARMLIB SUBSYS(TSO,INTERVAL(01)) -- PARMLIB SUBSYS(TSO,EXITS(IEFUSO)) -- PARMLIB SUBSYS(TSO,EXITS(IEFUJP)) -- PARMLIB SUBSYS(TSO,EXITS(IEFU84)) -- PARMLIB SUBSYS(TSO,EXITS(IEFU83)) -- PARMLIB SUBSYS(TSO,EXITS(IEFU29)) -- PARMLIB SUBSYS(STC,NOTYPE(16,19,90,99)) -- SYS SUBSYS(STC,NODETAIL) -- SYS SUBSYS(STC,INTERVAL(003000)) -- PARMLIB SUBSYS(STC,EXITS(IEFUSO)) -- PARMLIB SUBSYS(STC,EXITS(IEFUJP)) -- PARMLIB SUBSYS(STC,EXITS(IEFU84)) -- PARMLIB SUBSYS(STC,EXITS(IEFU83)) -- PARMLIB SUBSYS(STC,EXITS(IEFU29)) -- PARMLIB SYS(NODETAIL) -- PARMLIB SYS(INTERVAL(003000)) -- PARMLIB SYS(EXITS(IEFU29)) -- PARMLIB SYS(EXITS(IEFUTL)) -- PARMLIB SYS(EXITS(IEFUJI)) -- PARMLIB SYS(EXITS(IEFUSI)) -- PARMLIB SYS(EXITS(IEFUJV)) -- PARMLIB SYS(EXITS(IEFACTRT)) -- PARMLIB SYS(EXITS(IEFU84)) -- PARMLIB SYS(EXITS(IEFU83)) -- PARMLIB SYS(NOTYPE(16,19,90,99)) -- PARMLIB LISTDSN -- PARMLIB SID(MVSE) -- DEFAULT JWT(0058) -- PARMLIB STATUS(01) -- PARMLIB MAXDORM(1500) -- PARMLIB REC(PERM) -- PARMLIB NOPROMPT -- PARMLIB DSNAME(SYS1.MAN1E5) -- PARMLIB DSNAME(SYS1.MAN1E4) -- PARMLIB DSNAME(SYS1.MAN1E3) -- PARMLIB DSNAME(SYS1.MAN1E2) -- PARMLIB DSNAME(SYS1.MAN1E1) -- PARMLIB ACTIVE -- PARMLIB 2006/1/19, Knutson, Sam [EMAIL PROTECTED]: The output from the MVS operator command D SMF,O will show this and most of the other pertinent SMF configuration information of interest except CISIZE I think. Thanks, Sam Are you using any SMF exits such as IEFU29? Don Imbriale -- 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
Re: How SMFDUMP works?
It's possible the problem is with your IEFU29 exit. There's an item on IBMLink that mentioned this. Try starting SMF without the IEFU29 exit. When a switch from one of your SMF dump data sets occurs either because the data set is full or you manually switch it, see if the status of that data set changes to DUMP REQUIRED as expected. If it does, then you can take a look at your IEFU29 exit to see if there's a bug somewhere in there. Did you recently change the dsnames of your SMF dump data sets? Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Víctor de la Fuente Sent: Monday, January 23, 2006 3:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Yes, we are using it: MEMBER =3D SMFPRM1E MULCFUNC -- DEFAULT MEMLIMIT(0M) -- DEFAULT DDCONS(YES) -- DEFAULT LASTDS(MSG) -- DEFAULT NOBUFFS(MSG) -- DEFAULT SYNCVAL(00) -- DEFAULT INTVAL(30) -- DEFAULT DUMPABND(RETRY) -- DEFAULT SUBSYS(TSO,NOTYPE(16,19,90,99)) -- SYS SUBSYS(TSO,DETAIL) -- PARMLIB SUBSYS(TSO,INTERVAL(01)) -- PARMLIB SUBSYS(TSO,EXITS(IEFUSO)) -- PARMLIB SUBSYS(TSO,EXITS(IEFUJP)) -- PARMLIB SUBSYS(TSO,EXITS(IEFU84)) -- PARMLIB SUBSYS(TSO,EXITS(IEFU83)) -- PARMLIB SUBSYS(TSO,EXITS(IEFU29)) -- PARMLIB SUBSYS(STC,NOTYPE(16,19,90,99)) -- SYS SUBSYS(STC,NODETAIL) -- SYS SUBSYS(STC,INTERVAL(003000)) -- PARMLIB SUBSYS(STC,EXITS(IEFUSO)) -- PARMLIB SUBSYS(STC,EXITS(IEFUJP)) -- PARMLIB SUBSYS(STC,EXITS(IEFU84)) -- PARMLIB SUBSYS(STC,EXITS(IEFU83)) -- PARMLIB SUBSYS(STC,EXITS(IEFU29)) -- PARMLIB SYS(NODETAIL) -- PARMLIB SYS(INTERVAL(003000)) -- PARMLIB SYS(EXITS(IEFU29)) -- PARMLIB SYS(EXITS(IEFUTL)) -- PARMLIB SYS(EXITS(IEFUJI)) -- PARMLIB SYS(EXITS(IEFUSI)) -- PARMLIB SYS(EXITS(IEFUJV)) -- PARMLIB SYS(EXITS(IEFACTRT)) -- PARMLIB SYS(EXITS(IEFU84)) -- PARMLIB SYS(EXITS(IEFU83)) -- PARMLIB SYS(NOTYPE(16,19,90,99)) -- PARMLIB LISTDSN -- PARMLIB SID(MVSE) -- DEFAULT JWT(0058) -- PARMLIB STATUS(01) -- PARMLIB MAXDORM(1500) -- PARMLIB REC(PERM) -- PARMLIB NOPROMPT -- PARMLIB DSNAME(SYS1.MAN1E5) -- PARMLIB DSNAME(SYS1.MAN1E4) -- PARMLIB DSNAME(SYS1.MAN1E3) -- PARMLIB DSNAME(SYS1.MAN1E2) -- PARMLIB DSNAME(SYS1.MAN1E1) -- PARMLIB ACTIVE -- PARMLIB 2006/1/19, Knutson, Sam [EMAIL PROTECTED]: The output from the MVS operator command D SMF,O will show this and most of the other pertinent SMF configuration information of interest except CISIZE I think. Thanks, Sam Are you using any SMF exits such as IEFU29? Don Imbriale *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: How SMFDUMP works?
Hello Ed, Date formats can not be assumed. And this was extract from IBM SIS site. I read it as yy/mm/dd = 2002 August 26, On Wed, 18 Jan 2006 17:17:38 -0600, Ed Gould [EMAIL PROTECTED] wrote: On Jan 17, 2006, at 11:17 PM, Bruce Hewson wrote: Hello Victor, Have you checked your SMF TYPE 19 collection as per Shane and Sam's posts? Check out Info APAR: APAR Identifier .. II02887 Last Changed 02/08/26 SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD Bruce, 1926 ???!!! even MVS is not that old. Ed Regards Bruce -- 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
Re: How SMFDUMP works?
On Jan 19, 2006, at 5:35 AM, Bruce Hewson wrote: Hello Ed, Date formats can not be assumed. And this was extract from IBM SIS site. I read it as yy/mm/dd = 2002 August 26, I know this but it was a lame attempt at humor. There is always talk on here about the graying of us sysprogs. Sorry. Ed On Wed, 18 Jan 2006 17:17:38 -0600, Ed Gould [EMAIL PROTECTED] wrote: On Jan 17, 2006, at 11:17 PM, Bruce Hewson wrote: Hello Victor, Have you checked your SMF TYPE 19 collection as per Shane and Sam's posts? Check out Info APAR: APAR Identifier .. II02887 Last Changed 02/08/26 SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD Bruce, 1926 ???!!! even MVS is not that old. Ed Regards Bruce -- 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 -- 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
Re: How SMFDUMP works?
I'm not sure, but, yes I think so. 2006/1/18, Imbriale, Donald (Exchange) [EMAIL PROTECTED]: Are you using any SMF exits such as IEFU29? Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Víctor de la Fuente Sent: Wednesday, January 18, 2006 4:39 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Hi! I readed quickly all your answers!Thanks to all! My problem with the CLOSE PENDING is the file is not going DUMP REQUIRED forever...until it wants! I mean we don't know when it is going to change its status. Sometimes we waited for 20 minutes or more! So we need to know why it's not changing, because we'll go out of buffers if, any funny day, the file wants to stay in CLOSE PENDING for hours! Talking about SMF type records, we currently are NOT writing Type 19, 69 nor 99. When I can, I'll send you our SMFPRM member. I don't know the solution for my problem yet, but, this way, I'm sure I'll be a SMF expert in a few days!!! *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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 -- 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
Re: How SMFDUMP works?
The output from the MVS operator command D SMF,O will show this and most of the other pertinent SMF configuration information of interest except CISIZE I think. Thanks, Sam -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Víctor de la Fuente Sent: Thursday, January 19, 2006 12:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? I'm not sure, but, yes I think so. 2006/1/18, Imbriale, Donald (Exchange) [EMAIL PROTECTED]: Are you using any SMF exits such as IEFU29? Don Imbriale 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
Re: How SMFDUMP works?
I record Type 99 write them out during daily dump to a separate GDG and retain them for 5 days. If you have a problem with WLM it is easier to have the 99's than not. If I have this type of problem I expect to know about it soon enough to preserve the data. I equate them to data from a flight data recorder useful to have in the event of the unexpected. Here they represent less than 10% of the record volume. MQ, DB2, and CICS data dwarfs everything else and is constantly growing. If you have Cheryl Watson's TUNING Letter there was a nice little article Keeping WLM Type 99 Records in the 1998, No. 1 issue. I agree for many shops it makes sense to turn them off. 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 Paul Gillis Sent: Wednesday, January 18, 2006 2:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Shane Ginnane wrote: Now we only have the problems of the DUMP files in CLOSE PENDING STATUS. The solved problem was only today's problem, the CLOSE PENDING's one is much older... Did you check that type19 collection was turned off as suggested earlier ???. Else I'd be suspecting a coding bug - look for LOGREC software records about the same time as the switch. Check your SMFDUMP and IEFU29 code for errors - maybe time for a code update if you've been having this problem for some time. Shane ... I would also suppress record type 99. Currently if turned on at one of my customers, they make up approximately 80% of all SMF records generated. If you want to work out what SRM is doing, turn them on very briefly. I did examine the generation of type 19s a while ago but it was a reasonably small shop as far as DASD was concerned and the overhead was not a problem for them. Paul Gillis 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
Re: How SMFDUMP works?
If you have SAS MXG there is ANALSMF with MXG which provides a very useful analysis of SMF data contents and SMF data set buffer utilization. http://www.sas.com/ http://www.mxg.com/ THIS PROGRAM ANALYZES YOUR SMF DATA TO REPORT THE OPTIMUM VSAM CISIZE TO MINIMIZE THE SIZE OF YOUR VSAM SMF FILES, AND THE PROGRAM ALSO ANALYZES HOW FREQUENTLY VSAM RECORDS ARE WRITTEN AT YOUR SITE. YOU MUST SET THE CURRENT CISIZE IN USE AT YOUR SITE IN THE MACRO _MYCISIZ FOR THE FREQUENCY ANALYSIS. THE PROGRAM ALSO ANALYZES THE SMF FILE TO PRODUCE REPORTS WHICH DESCRIBE HOW MANY SMF CONTROL-INTERVALS (I.E., BLOCKS) WERE WRITTEN ON EACH SYSTEM, AND WITHIN THOSE PEAK THIRTY SECONDS, THIS PROGRAM IDENTIFIES THE SOURCE OF THE SMF DATA (RMF, JOB-ACCT, JOB-IO, CICS, ETC.), AND THE FINAL REPORT IDENTIFIES THE RECORD IDS WITHIN EACH SOURCE FOR EACH SECOND. If you have SAS already either on a PC or the mainframe and support z/OS investing in MXG one of the few real no brainer expenses you can make. 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 Víctor de la Fuente Sent: Tuesday, January 17, 2006 5:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Then I have another problem...we use z/OS 1.4! Nevertheless, we already thought about the problem you said. But our system is about 80% CPU, and we are used to be in 100%. I know there is no implication with cpu and smf writing, but I can suppose we had more smf writing per second a lot of times. The only possibility, I think, is any new program who is making SMF work hard. But I don't know how can we look for a program who is writing a lot of SMF data... :-( So, now we have two problems: - Dump file stays in CLOSE PENDING STATUS for a long time. - It looks like SMF is getting slow in writing records to dump file (because I'm almost sure there is no more writing than usual). Can they be two sympthoms of the same problem? 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
Re: How SMFDUMP works?
On 1/17/2006 2:38 AM, Víctor de la Fuente wrote: Our problem is also SMF starts losing data before all files are full: IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE TIME=08:19:30 ... D SMF IEE974I 08.20.04 SMF DATA SETS 177 NAMEVOLSER SIZE(BLKS) %FULL STATUS P-SYS1.MAN1E1 CGEHAA 43200 100 CLOSE PENDING S-SYS1.MAN1E2 CGEHAB 4320016 ACTIVE S-SYS1.MAN1E3 CGEHAC 43200 0 ALTERNATE S-SYS1.MAN1E4 CGEHAD 43200 0 ALTERNATE S-SYS1.MAN1E5 CGEHAE 43200 0 ALTERNATE So sys1.man1e1 does not reach Dump Required state, and also SMF has used all of his space available... The fact that SYS1.MAN1E1 is CLOSE PENDING rather than DUMP REQUIRED does not seem relevant to your problem. You DO have an ACTIVE data set: SYS1.MAN1E2, which should be able to record the records. Thus, the switch has occurred, even if the old data set is not yet available for dumping. Assuming that SYS1.MAN1E1 does go to DUMP REQUIRED and you can dump it, before you fill SYS1.MAN1E5, then your only problem is that your in-storage buffers are filling before they can be written to SYS1.MAN1E2, and for that you need more buffers or faster DASD, I think. Walt -- 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
Re: How SMFDUMP works?
Walt Farrell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On 1/17/2006 2:38 AM, Víctor de la Fuente wrote: Our problem is also SMF starts losing data before all files are full: IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE TIME=08:19:30 ... D SMF IEE974I 08.20.04 SMF DATA SETS 177 NAMEVOLSER SIZE(BLKS) %FULL STATUS P-SYS1.MAN1E1 CGEHAA 43200 100 CLOSE PENDING S-SYS1.MAN1E2 CGEHAB 4320016 ACTIVE S-SYS1.MAN1E3 CGEHAC 43200 0 ALTERNATE S-SYS1.MAN1E4 CGEHAD 43200 0 ALTERNATE S-SYS1.MAN1E5 CGEHAE 43200 0 ALTERNATE So sys1.man1e1 does not reach Dump Required state, and also SMF has used all of his space available... The fact that SYS1.MAN1E1 is CLOSE PENDING rather than DUMP REQUIRED does not seem relevant to your problem. You DO have an ACTIVE data set: SYS1.MAN1E2, which should be able to record the records. Thus, the switch has occurred, even if the old data set is not yet available for dumping. Assuming that SYS1.MAN1E1 does go to DUMP REQUIRED and you can dump it, before you fill SYS1.MAN1E5, then your only problem is that your in-storage buffers are filling before they can be written to SYS1.MAN1E2, and for that you need more buffers or faster DASD, I think. Walt He probably only needs more buffers, because (again probably) SMF is only busy accepting and buffering the flood of records and does not have time for closing older datasets, nor for writing buffers, in which case faster dasd will not help. Sufficient buffers to store records until the flood ends, will make SMF return to its normal work, such as writing records to dasd. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- 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
Re: How SMFDUMP works?
Hi Victor, Best answer is get to z/OS R6 where the SMF buffering just works better and is easily expanded. Since you said you were currently on R4 though you can do this with a USERMOD. As Walt suggested get yourself some more buffers. Paul Gillis kindly shared his on the MXG-L list a while ago. You need to carefully review OW56001 and make sure you have enough resources to support whatever you specify! We set our SMF buffer sizes on OS/390 2.10 and z/OS 1.4 as follows, and have not since seen any SMF buffer problems since applying the USERMOD. ++ USERMOD(LIEE001) REWORK(2004163) DESC(Zaps to SMFLIM to reset SMF Default Values). ++VER(Z038) FMID(HBB7707) PRE(UW94068). ++ZAP(IEEMB822). NAME SMFLIMS VER 0008 * Initial buffer size (8 meg) VER 0004 0008 * Buffer increment size (8 meg) VER 0008 0080 * Maximum buffer size (128 meg) VER 000C 0019 * Buffer warning level (25%) REP 0080 * Initial buffer size (128 meg) REP 0004 0020 * New Increment size = 32 meg REP 0008 0400 * New Maximum size = 1024 meg REP 000C 0032 * New Warning level = 50% Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Murphy's Computer Law 39: An ounce of image is worth a pound of performance. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Wednesday, January 18, 2006 10:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? On 1/17/2006 2:38 AM, Víctor de la Fuente wrote: Our problem is also SMF starts losing data before all files are full: IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE TIME=08:19:30 ... D SMF IEE974I 08.20.04 SMF DATA SETS 177 NAMEVOLSER SIZE(BLKS) %FULL STATUS P-SYS1.MAN1E1 CGEHAA 43200 100 CLOSE PENDING S-SYS1.MAN1E2 CGEHAB 4320016 ACTIVE S-SYS1.MAN1E3 CGEHAC 43200 0 ALTERNATE S-SYS1.MAN1E4 CGEHAD 43200 0 ALTERNATE S-SYS1.MAN1E5 CGEHAE 43200 0 ALTERNATE So sys1.man1e1 does not reach Dump Required state, and also SMF has used all of his space available... The fact that SYS1.MAN1E1 is CLOSE PENDING rather than DUMP REQUIRED does not seem relevant to your problem. You DO have an ACTIVE data set: SYS1.MAN1E2, which should be able to record the records. Thus, the switch has occurred, even if the old data set is not yet available for dumping. Assuming that SYS1.MAN1E1 does go to DUMP REQUIRED and you can dump it, before you fill SYS1.MAN1E5, then your only problem is that your in-storage buffers are filling before they can be written to SYS1.MAN1E2, and for that you need more buffers or faster DASD, I think. Walt 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
Re: How SMFDUMP works?
Also be sure to exclude type 69 records. See APAR OW45020 or the SMF manual for details. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Hewson Sent: Wednesday, January 18, 2006 12:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Hello Victor, Have you checked your SMF TYPE 19 collection as per Shane and Sam's posts? Check out Info APAR: APAR Identifier .. II02887 Last Changed 02/08/26 SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD We had this problem on some of systems some time ago. I am trying to locate the details, but, of course, I cant locate it now. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: How SMFDUMP works?
Hi Don, We currently exclude type 69 but I browsed the APARs to see if there was anything new and surprise... COMMENTS: The MVS Allocation and SMF components have agreed to accept this situation as a SUGgestion to be implemented through future development. The solution to this APAR is included in the base code for z/OS 1.6 (HBB7709). So at R6 and above (not Victor) it may no longer matter to have 69 listed as a NOTYPE. There won't be any type 69 records unless IBM decides to reuse the type for something else but eliminates another quirky entry in a PARMLIB member. 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 Imbriale, Donald (Exchange) Sent: Wednesday, January 18, 2006 11:51 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Also be sure to exclude type 69 records. See APAR OW45020 or the SMF manual for details. Don Imbriale 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
Re: How SMFDUMP works?
Hi! I readed quickly all your answers!Thanks to all! My problem with the CLOSE PENDING is the file is not going DUMP REQUIRED forever...until it wants! I mean we don't know when it is going to change its status. Sometimes we waited for 20 minutes or more! So we need to know why it's not changing, because we'll go out of buffers if, any funny day, the file wants to stay in CLOSE PENDING for hours! Talking about SMF type records, we currently are NOT writing Type 19, 69 nor 99. When I can, I'll send you our SMFPRM member. I don't know the solution for my problem yet, but, this way, I'm sure I'll be a SMF expert in a few days!!! -- 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
Re: How SMFDUMP works?
Are you using any SMF exits such as IEFU29? Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Víctor de la Fuente Sent: Wednesday, January 18, 2006 4:39 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How SMFDUMP works? Hi! I readed quickly all your answers!Thanks to all! My problem with the CLOSE PENDING is the file is not going DUMP REQUIRED forever...until it wants! I mean we don't know when it is going to change its status. Sometimes we waited for 20 minutes or more! So we need to know why it's not changing, because we'll go out of buffers if, any funny day, the file wants to stay in CLOSE PENDING for hours! Talking about SMF type records, we currently are NOT writing Type 19, 69 nor 99. When I can, I'll send you our SMFPRM member. I don't know the solution for my problem yet, but, this way, I'm sure I'll be a SMF expert in a few days!!! *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: How SMFDUMP works?
On Jan 17, 2006, at 11:17 PM, Bruce Hewson wrote: Hello Victor, Have you checked your SMF TYPE 19 collection as per Shane and Sam's posts? Check out Info APAR: APAR Identifier .. II02887 Last Changed 02/08/26 SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD Bruce, 1926 ???!!! even MVS is not that old. Ed -- 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
Re: How SMFDUMP works?
1926 ???!!! even MVS is not that old. But, some of the SYSPROGs are! -teD Me? A skeptic? I trust you have proof! -- 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
Re: How SMFDUMP works?
At 17:17 -0600 on 01/18/2006, Ed Gould wrote about Re: How SMFDUMP works?: On Jan 17, 2006, at 11:17 PM, Bruce Hewson wrote: Hello Victor, Have you checked your SMF TYPE 19 collection as per Shane and Sam's posts? Check out Info APAR: APAR Identifier .. II02887 Last Changed 02/08/26 SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD Bruce, 1926 ???!!! even MVS is not that old. Year/Month/Day - IOW: August 28, 2002. Ed -- 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
Re: How SMFDUMP works?
Víctor de la Fuente [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Our problem is also SMF starts losing data before all files are full: IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE TIME=08:19:30 .. D SMF IEE974I 08.20.04 SMF DATA SETS 177 NAMEVOLSER SIZE(BLKS) %FULL STATUS P-SYS1.MAN1E1 CGEHAA 43200 100 CLOSE PENDING S-SYS1.MAN1E2 CGEHAB 4320016 ACTIVE S-SYS1.MAN1E3 CGEHAC 43200 0 ALTERNATE S-SYS1.MAN1E4 CGEHAD 43200 0 ALTERNATE S-SYS1.MAN1E5 CGEHAE 43200 0 ALTERNATE So sys1.man1e1 does not reach Dump Required state, and also SMF has used all of his space available... Any idea? Yes, I have: the problem is with the in-storage SMF buffers, which are filled more rapidly than SMF can write them out to the MAN datasets. See the z/OS 1.6(+) version of System Messages for an explanation and a solution to enlarge SMF buffers via SMFPRMxx. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- 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
Re: How SMFDUMP works?
Then I have another problem...we use z/OS 1.4! Nevertheless, we already thought about the problem you said. But our system is about 80% CPU, and we are used to be in 100%. I know there is no implication with cpu and smf writing, but I can suppose we had more smf writing per second a lot of times. The only possibility, I think, is any new program who is making SMF work hard. But I don't know how can we look for a program who is writing a lot of SMF data... :-( So, now we have two problems: - Dump file stays in CLOSE PENDING STATUS for a long time. - It looks like SMF is getting slow in writing records to dump file (because I'm almost sure there is no more writing than usual). Can they be two sympthoms of the same problem? Thank you very much all! 2006/1/17, Vernooy, C.P. - SPLXM [EMAIL PROTECTED]: Yes, I have: the problem is with the in-storage SMF buffers, which are filled more rapidly than SMF can write them out to the MAN datasets. See the z/OS 1.6(+) version of System Messages for an explanation and a solution to enlarge SMF buffers via SMFPRMxx. Kees. -- 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
Re: How SMFDUMP works?
Victor, for z/OS 1.4 there is an USERMOD to zap the values. Check IBM. To see who is filling SMF, check the records that have been recorded and later written. The offender will probably have produced the most of the written records before causing problems. I cannot help you with the other problem. Kees. Víctor de la Fuente [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Then I have another problem...we use z/OS 1.4! Nevertheless, we already thought about the problem you said. But our system is about 80% CPU, and we are used to be in 100%. I know there is no implication with cpu and smf writing, but I can suppose we had more smf writing per second a lot of times. The only possibility, I think, is any new program who is making SMF work hard. But I don't know how can we look for a program who is writing a lot of SMF data... :-( So, now we have two problems: - Dump file stays in CLOSE PENDING STATUS for a long time. - It looks like SMF is getting slow in writing records to dump file (because I'm almost sure there is no more writing than usual). Can they be two sympthoms of the same problem? Thank you very much all! 2006/1/17, Vernooy, C.P. - SPLXM [EMAIL PROTECTED]: Yes, I have: the problem is with the in-storage SMF buffers, which are filled more rapidly than SMF can write them out to the MAN datasets. See the z/OS 1.6(+) version of System Messages for an explanation and a solution to enlarge SMF buffers via SMFPRMxx. Kees. -- 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 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- 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
Re: How SMFDUMP works?
OK! Thanks all! One of the problems is gone. We found some DASD problem, we solved them and...voilà! Now we only have the problems of the DUMP files in CLOSE PENDING STATUS. The solved problem was only today's problem, the CLOSE PENDING's one is much older... Who is the responsible for changing the status from CLOSE PENDING to DUMP REQUIRED? Thanks again!!! P.D.: I'm not a good English speaker. What does IIRC means??? ( IIRC this can still cause delays switching ...) -- 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
Re: How SMFDUMP works?
IIRC = If I Recall Correctly You can lookup acronym's here http://www.acronymfinder.com/ Thanks, Sam -Original Message- P.D.: I'm not a good English speaker. What does IIRC means??? ( IIRC this can still cause delays switching ...) 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
Re: How SMFDUMP works?
Thanks for the link! It'll be my most visited page!!! XD 2006/1/17, Knutson, Sam [EMAIL PROTECTED]: IIRC = If I Recall Correctly You can lookup acronym's here http://www.acronymfinder.com/ Thanks, Sam -Original Message- P.D.: I'm not a good English speaker. What does IIRC means??? ( IIRC this can still cause delays switching ...) 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 -- 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
Re: How SMFDUMP works?
On Jan 17, 2006, at 3:35 AM, Vernooy, C.P. - SPLXM wrote: Víctor de la Fuente [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Our problem is also SMF starts losing data before all files are full: IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE TIME=08:19:30 .. D SMF IEE974I 08.20.04 SMF DATA SETS 177 NAMEVOLSER SIZE(BLKS) %FULL STATUS P-SYS1.MAN1E1 CGEHAA 43200 100 CLOSE PENDING S-SYS1.MAN1E2 CGEHAB 4320016 ACTIVE S-SYS1.MAN1E3 CGEHAC 43200 0 ALTERNATE S-SYS1.MAN1E4 CGEHAD 43200 0 ALTERNATE S-SYS1.MAN1E5 CGEHAE 43200 0 ALTERNATE So sys1.man1e1 does not reach Dump Required state, and also SMF has used all of his space available... Any idea? Yes, I have: the problem is with the in-storage SMF buffers, which are filled more rapidly than SMF can write them out to the MAN datasets. See the z/OS 1.6(+) version of System Messages for an explanation and a solution to enlarge SMF buffers via SMFPRMxx. Kees. I have been watching this thread and have wondered if the reason why the the switch is not processinging quickly is, if the dump datasets have been primed? Ed -- 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
Re: How SMFDUMP works?
Now we only have the problems of the DUMP files in CLOSE PENDING STATUS. The solved problem was only today's problem, the CLOSE PENDING's one is much older... Did you check that type19 collection was turned off as suggested earlier ???. Else I'd be suspecting a coding bug - look for LOGREC software records about the same time as the switch. Check your SMFDUMP and IEFU29 code for errors - maybe time for a code update if you've been having this problem for some time. Shane ... -- 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
Re: How SMFDUMP works?
Hello Victor, Have you checked your SMF TYPE 19 collection as per Shane and Sam's posts? Check out Info APAR: APAR Identifier .. II02887 Last Changed 02/08/26 SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD We had this problem on some of systems some time ago. I am trying to locate the details, but, of course, I cant locate it now. Regards Bruce Hewson -- 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
Re: How SMFDUMP works?
Shane Ginnane wrote: Now we only have the problems of the DUMP files in CLOSE PENDING STATUS. The solved problem was only today's problem, the CLOSE PENDING's one is much older... Did you check that type19 collection was turned off as suggested earlier ???. Else I'd be suspecting a coding bug - look for LOGREC software records about the same time as the switch. Check your SMFDUMP and IEFU29 code for errors - maybe time for a code update if you've been having this problem for some time. Shane ... I would also suppress record type 99. Currently if turned on at one of my customers, they make up approximately 80% of all SMF records generated. If you want to work out what SRM is doing, turn them on very briefly. I did examine the generation of type 19s a while ago but it was a reasonably small shop as far as DASD was concerned and the overhead was not a problem for them. Paul Gillis -- 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
How SMFDUMP works?
Hi all! I was wondering which is the process of clearing SMF datasets. We are having a problem, and I'd like to know the process to see which is that problem. When one SMF dataset is full, it should get into DUMP REQUIRED state to be cleared. The problem we are having is that, sometimes (randomly in time) the dataset stays in CLOSE PENDING for several minutes). If the charge of the system is high, that time is plenty to let SMF fill up all of its 128 MBs, so we start to lose data. Could some of you tell me when the dataset changes its state, and why? Thank you very much -- 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
Re: How SMFDUMP works?
Hi Victor, Are you perhaps recording Type 19 records? If not why don't you post your SMF parms. Here is our SMFPRMxx and like most sites I expect we exclude type 19. IIRC this can still cause delays switching SMF data sets. z/OS R6 improves the handling of SMF buffers considerably and makes it practical to allow SMF more than 128M. SYS1.PARMLIB(SMFPRM00) - 01.10 CHARS 'NOTYP === Scroll = Top of Data * ACTIVE /* ACTIVE SMF RECORDING */ DSNAME(SYS1.SYSNAME..MAN1, SYS1.SYSNAME..MAN2, SYS1.SYSNAME..MAN3, SYS1.SYSNAME..MAN4) NOPROMPT/* DO NOT PROMPT OPERATOR */ REC(PERM) /* TYPE 17 PERM RECORDS ONLY*/ MAXDORM(1500) /* WRITE IDLE BUFFER AFTER 30 MIN */ MEMLIMIT(4G)/* ALLOW USE OF STORAGE ABOVE BAR */ BUFSIZMAX(512M) /* 4X DEFAULT IBM BUFFERS */ STATUS(003000) /* WRITE SMF STATS AFTER 1 HOUR */ JWT(0015) /* 522 AFTER 15 MINUTES */ SID(SYSNAME) /* UNIQUE TO EACH LPAR IN SYSPLEX */ LISTDSN /* LIST DATA SET STATUS AT IPL */ SYS(NOTYPE(4,5,19,20,34,35,40,69,120),INTERVAL(01),NODETAIL, EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUTL,IEFUSI,IEFUJI,IEFU29)) SUBSYS(STC,EXITS(IEFUSI,IEFU29,IEFU83,IEFU84,IEFU85)), SUBSYS(TSO, EXITS(IEFACTRT,IEFUJI,IEFUSI,IEFUTL,IEFU29,IEFU83,IEFU84,IEFU85)) 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 Víctor de la Fuente Sent: Monday, January 16, 2006 8:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: How SMFDUMP works? Hi all! I was wondering which is the process of clearing SMF datasets. We are having a problem, and I'd like to know the process to see which is that problem. When one SMF dataset is full, it should get into DUMP REQUIRED state to be cleared. The problem we are having is that, sometimes (randomly in time) the dataset stays in CLOSE PENDING for several minutes). If the charge of the system is high, that time is plenty to let SMF fill up all of its 128 MBs, so we start to lose data. Could some of you tell me when the dataset changes its state, and why? Thank you very much 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
Re: How SMFDUMP works?
At 14:54 +0100 on 01/16/2006, Víctor de la Fuente wrote about How SMFDUMP works?: Hi all! I was wondering which is the process of clearing SMF datasets. We are having a problem, and I'd like to know the process to see which is that problem. When one SMF dataset is full, it should get into DUMP REQUIRED state to be cleared. The problem we are having is that, sometimes (randomly in time) the dataset stays in CLOSE PENDING for several minutes). If the charge of the system is high, that time is plenty to let SMF fill up all of its 128 MBs, so we start to lose data. Could some of you tell me when the dataset changes its state, and why? Thank you very much While I can not help you with your Slow Close problem, I can offer some assistance with your All Files Full one. Why not increase the size of the MAN Datasets or allocate more of them? So long as at least one is not full (either because of its size [when it is the active one] or the number you have defined [ie: There is still at least one that is empty and can be switched to]) you will not get an All Files Full - Data has no where to be dumped when the buffers fill condition. -- 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
Re: How SMFDUMP works?
Our problem is also SMF starts losing data before all files are full: IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE TIME=08:19:30 ... D SMF IEE974I 08.20.04 SMF DATA SETS 177 NAMEVOLSER SIZE(BLKS) %FULL STATUS P-SYS1.MAN1E1 CGEHAA 43200 100 CLOSE PENDING S-SYS1.MAN1E2 CGEHAB 4320016 ACTIVE S-SYS1.MAN1E3 CGEHAC 43200 0 ALTERNATE S-SYS1.MAN1E4 CGEHAD 43200 0 ALTERNATE S-SYS1.MAN1E5 CGEHAE 43200 0 ALTERNATE So sys1.man1e1 does not reach Dump Required state, and also SMF has used all of his space available... Any idea? 2006/1/17, Robert A. Rosenberg [EMAIL PROTECTED]: At 14:54 +0100 on 01/16/2006, Víctor de la Fuente wrote about How SMFDUMP works?: Hi all! I was wondering which is the process of clearing SMF datasets. We are having a problem, and I'd like to know the process to see which is that problem. When one SMF dataset is full, it should get into DUMP REQUIRED state to be cleared. The problem we are having is that, sometimes (randomly in time) the dataset stays in CLOSE PENDING for several minutes). If the charge of the system is high, that time is plenty to let SMF fill up all of its 128 MBs, so we start to lose data. Could some of you tell me when the dataset changes its state, and why? Thank you very much While I can not help you with your Slow Close problem, I can offer some assistance with your All Files Full one. Why not increase the size of the MAN Datasets or allocate more of them? So long as at least one is not full (either because of its size [when it is the active one] or the number you have defined [ie: There is still at least one that is empty and can be switched to]) you will not get an All Files Full - Data has no where to be dumped when the buffers fill condition. -- 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 -- 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
