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