RE: LPAR and Performance

There aren't any additional costs on the IBM side from a software
perspective.  There may be some from a hardware perspective, though, as
the number of disks required to support multiple LPARs may grow.  And
how you structure the optical and tape devices will determine if you can
get by with 1 or need 2 of each.  BTW, the 15K disks in the i5 machines
are screamers and you can easily get by with fewer disks than your 720
had.  I recently went from 62 drives in a 730 to 18 drives in an i5 and
disk throughput went up by at least 40% (I haven't measured it exactly
yet, but it's way way better).

There could be additional costs for LPARing from your 3rd party software
vendors.  Some charge an LPAR fee or additional modest fee per LPAR.  I
suppose their thinking is that there are more app instances and as such
there is more potential for support costs, but my thinking is that I
licensed the software for a box with n CPW; it shouldn't matter how I
slice it up.

If you are in a publicly held company, you may have audit requirements
that developers not be allowed near production data; in these cases
LPARing is an easy solution. 

In addition, I would recommend you separate your source, compiled
program objects, and data to three separate libraries.  For one thing,
you can choose to just save your data nightly instead of everything and
the resulting saves are easier to manage.  For another, some OS
operations have operational overhead associated with every object in a
library; using more libraries minimizes this effect.  And another: I
assume users are authorized to the production library right now; why are
they authorized to source?

If you do the LPARed environment, your migrations should be pretty
straightforward.  Read the IBM manuals for some clues and post any
questions here.

Also, once LPARed, you might consider using the SAVRST commands to move
objects between LPARs.  It is simple to use once set up.