Re: Copying data and/or metadata across LPAR boundaries

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

As to IASPs - to connect one of those to a different LPAR requires that 
the DASD that comprises the IASP is in a tower separate from the CEC. At 
least that's how I understand the pictures in the latest Redbook on IASPs.

Still, because James is a vendor, and he is talking about doing things 
on a customer machine, I believe, things like IASPs and even SAVRST* 
commands just can't be relied upon, in my opinion - sort of like 
requiring that QShell be installed in order for your product to work - 
not hard, no extra cost, just can't rely on it being on the box.

IF IASPs broke TAATOOLS, well, they have some work to do. It's just NOT 
that hard to make a product work in a stand-alone IASP - and switchable 
isn't that much harder - more to do with licensing than anything else, 
in my experience. We have people running our products in IASPs now and 
have had no problem or real challenges.

Vern

On 6/10/2011 11:21 AM, rob@xxxxxxxxx wrote:
> Basically the techniques I am seeing do not differ between a customer with
> multiple lpars, and a customer with two different boxes in two different
> cities.  I was just trying to think "inside" the box.
>
> With iasp, couldn't you put your "templates" into an iasp then connect it
> to which lpar you wanted to generate on?
>
> Another option may be something like sharing between a couple of guested
> lpars.  How hard would it be to put one of the WRKNWSSTG drives into it's
> own asp.  Kill it on one lpar and activate in on another?  May, or may
> not, be applicable to what he's trying to accomplish, but just throwing
> ideas out on the wall.
>
> I think there are some out there who felt like iASP's were the tool of the
> devil.  I suspect it had more to do with breaking numerous TAATOOLs more
> than anything else.  Sort of like the wailing and gnashing of teeth when
> IBM allowed you to increase the number of spool files per job.
>
>
> Rob Berendt