I agree that using IBM i subsystems and libraries to isolate and manage
workloads may compete against the idea of using LPARs. But my questions
were asked with an open mind, and I am listening. We benefit by having a
separate development box. But I'm the one doing the PTFs and OS upgrades
and getting a sense of the cost of managing 2 systems.
We're using subsystems, libraries, and soft-coded library lists as part of
a SAAS business model. All of our applications have browser user
interfaces. We don't give customers access to command lines.
I set up the 60 runtime environments last week by calling a CL program
which runs the commands for setting up the subsystems and libraries for an
individual client. Last week I evoked that program from an RPG program
which looped through a client list. The whole process ran in something like
The process can be used to setup various development and test environments,
in addition to separate environments for separate customers.
At some point, I intend on exposing the process to prospective customers,
who might fill out a browser form, then receive an email containing a
hyperlink to a login page for their web portal entry-point.
Everything I have read about setting up IBM i LPARS appears to involve an
HMC type user interface, a technical expert, and a fairly significant
number of steps. What are LPAR scripts and how they work?
On Tue, Jun 10, 2014 at 11:35 PM, Evan Harris <auctionitis@xxxxxxxxx> wrote:
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-2014 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