I think your last statement is telling:
"I believe it will be much easier to to manage 60 such soft-coded
environments than 60 LPARS."
So long as you "believe" this, any discussion to the contrary likely falls
on deaf ears.
Some of the reasons we end up deploying separate LPARs for clients is (in
no particular order):
- Separation of workload(s)
- Creation of QA/Test environments
- Copies of Production environments
- A general desire to have a dedicated system environment for one reason or
This is by no means an exhaustive list as other posts have indicated.
It's pretty easy to create a new LPAR - certainly no more complicated than
creating 60 subsystems along with the associated jobqs, routing entries,
outqueues, user profiles, job descriptions, libraries and all the other
paraphernalia that doing things this way requires (I think you made this
sound way simpler than it really is). It's just a different mindset and a
different set of commands.
Where a separate LPAR helps is in things like maintaining separate System
values, providing root access (where it is sensible), duplicating library
For a vendor it also helps in getting the customer to "believe" their
environment is completely separate and dedicated to them. They understand
the concept of a Virtual Machine well enough. Explaining how separate
libraries, job queues, etc would segregate the workload and data would in
many cases be a tough sell.
You should also take into account that what you are doing is pretty
non-typical in my experience. It's rare to encounter a system that runs
primarily one application, totally controlled by in house application
specialists(s) with no other applications competing on the system. Most
systems have a number of applications that don't necessarily want to
co-exist with anything else and/or in-house code that has not been as
carefully crafted as your applications clearly have.
You are truly fortunate that your applications have been built in the way I
get the impression they have.
You are only serving an application and conceivably you have sufficient
control that you can configure a new application without needing the
additional insulation a complete LPAR affords you. This is not the same as
hosting or providing a complete environment for a different workload, for
separate customers looking for a completely dedicated system for their
Separate LPARs also provides much better - and more demonstrably visible
- workload segregation as access to CPU and memory is much more clearly
defined than in your scenario - unless you also created another 60
dedicated storage pools.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
This mailing list archive is Copyright 1997-2015 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact