When you "immediately take offline" the unneeded devices, I presume you mean in some EXEC after the IPL completes?
Might the control blocks not even be built of you get a bit more picky in SYSTEM CONFIG with: DEVICES OFFLINE_AT_IPL rdev-rdev ... etc. I do not know for fact, but having CP take them offline at IPL may help reduce MONDCSS storage (and perhaps CP control block structures) with little effort. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. RPN01 <nix.rob...@mayo.edu> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 03/30/2010 01:14 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: [?? Probable Spam] Re: Perfkit SAMPLE CONFIG size too small I plan to talk to the hardware people in a moment to see if anything was added recently? We do have a large amount of DASD that is really owned by z/OS, which we immediately take offline, but they?d still be in the config area. -- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/30/10 11:21 AM, "Eginhard Jaeger" <e.jae...@ch.inter.net> wrote: This is usually caused by zVM accessing lots of additional I/O devices that it previously didn't see. While redefining the CONFIG size and the size of the MONDCSS can allow CP to again pack all of the available information into its monitor data, all of the additional monitor records must also be processed. The FCXPMN44E message means probably that PerfKit couldn't process the data fast enough, i.e. it needs a higher share of the CPU. But check first whether the problem is really caused by additional I/O devices. Is your VM seeing lots of devices belonging to other LPARs? Vary off the ones that are not needed, or tell the monitor via MONITOR command not to collect data for the ones you're not interested in. Eginhard My questions now are, What happened to the prior segment that caused it to fail? Could the problem have been avoided, and how? Also, now I?m getting the following two messages, repeatedly, and we?re still not collecting any data: FCXPMN444E IUCV reply failed with reason code 9 HCPMOV6274I The sample data messages and corresponding records have been purged. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
