RE: Msg: IBM i usage limit exceeded - operator action required (CPF9E7F)

I have been fighting with this same error for quite a while and maybe one of you can shed some light on it. I am running V7R3 (my machine is capped at that release).

I have 2 partitions MIDOHIO and MIDOHIO2. MIDOHIO2 is a virtual partition. I do not have an HMC. Since I rarely use MIDOHIO2 (most of the time it is not even powered up) I have just been ignoring the problem.

Below are the two partition configs. I configured both partitions to be min / max of 1 processor. So why am I getting an error that I my usage limit was exceeded? IBM's response when I opened a ticket was "Use the Field Core Override (FCO) function in Advanced System Management (ASM) on the service processor to turn off all but the one processor you have a license for." Is this just a bug in virtual partitions that allows it to use more than the max processors?

Partition identifier and name . . . . . . . : 1 MIDOHIO

Number of partition processors . . . . . . . : 1
Minimum / maximum number of processors . . . : 1 / 1
Use shared processor pool . . . . . . . . . : Yes
Shared processor pool units . . . . . . . : 0.50
Minimum / maximum processor pool units . . : 0.10 / 0.90
Uncapped processing . . . . . . . . . . . : Yes
Uncapped processing weight . . . . . . . : Med
Size of partition memory (MB) . . . . . . . : 3744
Minimum / maximum size of memory (MB) . . . : 1024 / 8192
Enable workload management . . . . . . . . . : No



Partition identifier and name . . . . . . . : 2 MIDOHIO2

Number of partition processors . . . . . . . : 1
Minimum / maximum number of processors . . . : 1 / 1
Use shared processor pool . . . . . . . . . : Yes
Shared processor pool units . . . . . . . : 0.50
Minimum / maximum processor pool units . . : 0.10 / 0.90
Uncapped processing . . . . . . . . . . . : Yes
Uncapped processing weight . . . . . . . : Med
Size of partition memory (MB) . . . . . . . : 2944
Minimum / maximum size of memory (MB) . . . : 1024 / 8096
Enable workload management . . . . . . . . . : No