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.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page