At one time we have about 2 dozen "AS/400's". When we consolidated we did
not simply make one partition for each machine. Actually now our ERP
library has them all combined. But, consolidation is one reason why
people do this. It's just easier for them.
We have a separate lpar for production versus development. True, much can
be done with security. However when your developers just insist on having
a higher level of access for development than they are going to get on
production separate lpars is one way to accommodate that. And it does
simplify testing versus production. I'm not saying you can't work around
that but this works for us.
Testing PTFs, OS releases, and whatnot. We can put them on our
development lpar before putting them on our production lpar.
Corollary: Training yourself on OS upgrades. By the time you've upgraded
a few lpars, many of whom can be upgraded during prime time, you've got
the process down pat so that when you do finally bring down that critical
lpar in off time you can burn right through it.
Really intense configurations. Like testing relational database directory
entries for Mimix high availability on your pair of development lpars
before implementing them on your production lpars.
Certain applications which are more prone to delayed ptf's can be put on a
separate lpar than something you'd rather IPL less frequently.
That piece of crap software that will not run on the latest OS can be put
on it's own lpar so that everything else can be upgraded to the latest
version of OS. (at least until you replace it.)
Your DMZ lpar versus your internal LPAR.
Disparate workloads and different tuning.
If I can run a full system save, RCLSTG, and what not simultaneously on
multiple lpars versus one long run I can reduce my outage lengths.
Now, keep in mind that you asked why people do this. I am telling you in
response to your question. I am NOT telling you so that you can argue on
why all of these reasons are wrong and that I really should be able to get
by with a single lpar per physical box.