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. >
