We IPL with type 19's turned off, and then enable in Command after IPL. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184
If you feel in control you just aren't going fast enough. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Dave Barry Sent: Monday, June 03, 2013 12:40 PM To: [email protected] Subject: Re: Longer SMFWAIT during IPL MSI I remember having this issue years ago when using the old IPO SMFDUMP program. We forced a switch at midnight and dumped the last of the previous day's data on two loosely coupled systems. IIRC, the type 19s were produced by the IEFU29 exit under a global IPO1.SMF enqueue. The two dumps' time frames never matched because one had to wait a long time for the other to issue the l-space macro against every device in the system before proceeding. "Record type 19 is written: 1. For each online device associated with a specific IPL time frame, 2. For each online device associated with a processed HALT EOD or SWITCH SMF command, and 3. When a direct access volume that is defined by DD statement is demounted." Therefore, the magnitude of the problem depends very much on the number of online devices and how fast their VTOCs can be read. Since our shop already had more modern DASD space reporting tools, we got rid of the problem by excluding type 19 in SMFPRMxx. db -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Shameem .K .Shoukath Sent: Friday, May 31, 2013 1:16 PM To: [email protected] Subject: Re: Longer SMFWAIT during IPL MSI Thanks Bob for sharing the REDBOOK details it is of good help to understand the process. We are recording 19 in all LPARs. I think storage team uses it for their reporting using 20% or something, im not sure. My actual question still stands when i compare PROD and DEV SMFPRMxx then only diff i see is the SMF EXIT IEFU84. Is this exit heavy by itself or by poor coding ? is this affecting performance POST IPL as this EXIT takes control before each SMF Write. I need to raise a CHANGE if i want to remove it and test. So I was expecting to get a feedback from the LIST whether it worth a try. I have to give some justification in the CHANGE to request the removal. ________________________________ Thanks and Regards Shameem K Shoukath >________________________________ > From: Bob Rutledge <[email protected]> >To: [email protected] >Sent: Thursday, May 30, 2013 8:55 PM >Subject: Re: Longer SMFWAIT during IPL MSI > > >I suggest this Redbook: > >http://publib-b.boulder.ibm.com/abstracts/sg247816.html?Open > >Bob > >Shameem .K .Shoukath wrote: >> >> hi there, >> >> I was just going thru the IPL statistics of all LPARs in out org. I >>see in one LPAR the SMFWAIT is taking fairly longer comp to others. >>out of total 00:01:12 MSI time this takes 00:00:53.586 >> >> I am not sure what happens in this process, took a chance & compared the >> SMFPRMxx and saw there is one exit IEFU84 additional compared to PROD and QA >> lpars. >> >> would this be the cause for slower IPL ? Will it also may be one reason >> contributing to performance issues? as i understand this exit gets control >> before each SMF write. >> >> >> >> >> *** IEEMB860 Statistics *** >> >> ILRTMRLG 00:00:00.278 ASM IEEVMSI 00:00:00.065 Reconfiguration >> IARM8MSI 00:00:00.030 RSM - bring storage online IECVIOSI >> 00:00:02.627 IOS dynamic pathing RACROUTE 00:00:00.000 Initialize >> Security Environment ATBINSYS 00:00:00.020 APPC IKJEFXSR >> 00:00:00.183 TSO >> IXGBLF00 00:00:00.029 Logger AXRINSTR 00:00:00.042 System REXX >> CEAINSTR 00:00:00.031 Common Event Adapter >> HWIAMIN1 00:00:00.067 BCPii COMMNDXX 00:00:00.091 COMMANDxx >> processing IEAVTMSI 00:00:00.071 RTM SMFWAIT 00:00:53.586 SMF >> ICHSEC05 00:00:12.113 Security Server MSIEXIT 00:00:00.000 >> Cnz_MSIExit Dynamic Exit >> IEFJSIN2 00:00:03.188 SSN= subsystem >> IEFHB4I2 00:00:00.015 ALLOCAS - UCB scan CSRINIT 00:00:00.005 >> Windowing services FINSHMSI 00:00:00.336 Wait for attached CMDs >> >> IEEMB860 00:01:12.797 Uncaptured time: 00:00:00.011 >> >> >> >> ________________________________ >> >> Thanks and Regards >> Shameem K Shoukath > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN "Email Firewall" made the following annotations. ------------------------------------------------------------------------------ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ============================================================================== ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
