× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Nathan

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
another

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

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

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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.