Re: Copying data and/or metadata across LPAR boundaries

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