|
The software I listed were just for examples. DBU, for example, could be installed into *SYSBASE and access database tables on any iASP currently connected. I don't see how the vendor would have a problem with that.
I would never imply you should cheat/steal on your software licensing. If you need to install copies of ERP software on multiple iASPs, or install the programs in *SYSBASE and the database on multliple iASPs, you would need to work out the licensing with your vendor. It still simplifies administration compared to LPARs for many installations.
Just offering an alternative for some.
On Sunday, June 15, 2014 12:27 PM, DrFranken <midrange@xxxxxxxxxxxx> wrote:
Vern hits some good highlights here. iASPs though share all devices and
user profiles and subsystems. Clearly subsystems have been mentioned
before as one tool to run multiple workloads in a single partition.
iASPS also share all system values such as date time and timezone as well.
Just like you would likely virtualize disk for multiple LPARs you would
do the same for multiple iASPs. Without that it makes it just as
expensive for disk as you'll need to add entire disk increments and of
course you'll want enough arms in in each iASP for performance.
Remember though the advantage of doing PTFS and other updates for one
LPAR with lots of iASPS means all users are off for that update. Yes
it's just outage for the update but no flexibility to leave some users
on and others off.
I do believe that iASPS are underused as they are poorly understood by
most, including almost every single package vendor.
- Larry "DrFranken" Bolhuis
www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
On 6/15/2014 11:20 AM, Vernon Hamberg wrote:
Joe
In one way I agree - I've felt that an IASP is like a junior LPAR - much
of what happens in an IPL takes place when varying on an IASP device.
I think an issue arises with regard to licensing for all the 3rd-party
items you list - if they are licensed by serial number, as many are,
then, yes, you'd have a single license that is usable on all IASPs. I
know that this was a challenge for us at RJS when I was there - and, in
fact, it could be seen as a way of getting around licensing, in effect
allowing multiple "instances" to be run on the same LPAR.
Another issue is that each LPAR has its own *SYSBAS - IASPs share one
*SYSBAS - how do you keep ROBOT data for one purpose segregated from
that for another purpose - and if these "purposes" are actually
different clients, this is a real issue - UNLESS you install multiple
copies of such a product on one LPAR - and that leads to my first issue.
Or I suppose you could put copies of the database for a product in each
IASP - again, are you violating the spirit of the licensing? It depends.
Another aspect of a *SYSBAS - it is basically all the space you have
left from IASPs and regular ASPs (numbers start with 2) - with IASPs you
have a limit - even regular ASPs will simply overflow into the *SYSBAS -
as I recall, there is no overflow with IASPs.
I think IASPs can be a pretty-good solution for test and production, for
evaluation of updates to products, perhaps. And still with some of the
concerns I have raised.
Vern
On 6/12/2014 4:35 PM, Joe Roden wrote:
It seems almost all of these could be handled with IASPs. The
advantage being you will save lots of money only paying one software
license for the operating system, DBU, ROBOT, any other utilities
software, etc. IASP groups can be secured the same as any other object
on the system.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
