Re: YAIQ - Yet another ignorant question: multiple LPARs.

Rob,

I don't think that's the type of sharing John's thinking about.

They way I understand it, he's used to having multiple LPARs being
able to access the same ASP at the same time.

Consider the way the SYSBAS ASP is shared when you have mulitple
IASPs. Except that instead of an IASP, you've got an actual LPAR.

Charles

On Sun, Dec 7, 2008 at 9:06 AM, <rob@xxxxxxxxx> wrote:

Yes lpars can share each other's physical disk drives and not the data.
Which sounds exactly like one of your lines.
You just need to be at V6R1. And it's called "guested" lpars. The
advantage is that if you total system has 30 disk arms you then have all
your lpars using all 30 disk arms instead of a to lpar 1, b to lpar 2, ...
The disadvantage is that if the hosting lpar goes down then so do all the
guested lpars.
I have this configured on two different racks.
Really freaks out the CE when he does a WRKDSKSTS on a guested lpar and
sees:
Size %
Unit Type (M) Used
1 6B22 279622 25.3

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
"McKown, John" <John.Mckown@xxxxxxxxxxxxxxxxx>
To:
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date:
12/05/2008 05:35 PM
Subject:
RE: YAIQ - Yet another ignorant question: multiple LPARs.
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Friday, December 05, 2008 3:47 PM
To: Midrange Systems Technical Discussion
Subject: Re: YAIQ - Yet another ignorant question: multiple LPARs.

John,

Your questions have been far from ignorant.

Thanks, but if I weren't igorant, I wouldn't have questions. <grin> I
just tend to have difficult questions, especially where the z just works
differently from the i. I haven't yet found a "iSeries for zSeries
dummies" type book.

However, since I've never worked on a z, I don't understand where you
are coming from with regards to the SYSPLEX.

A sysplex is a way for z/OS and subsystems to "talk" to each other to
coordinate changes and access to resources. For example, RACF is the
security system on the z. I have a single database which contains all
users and all access definations for all systems. Every LPAR can safely
and directly do I/O to that database on DASD because they "talk" via
sysplex communications to "enqueue" access as needed for updating.

I can't imagine sharing data between Development/QA and Production.
How does that work?

Very well <grin>. This may be something only terrible people do. Like to
debug a problem with a report which only reads production data, a test
version of the program is written and run against the actual production
data. It is considered "bad practice." But we have a LOT of stuff which
is "bad practice."

The idea behind an LPAR is that its logically a separate machine,
certain hardware devices can be moved between LPARS, but for all other
intents and purposes an LPAR is just like a physically separate box.

Same with the z, but physical hardware such as DASD devices can be
updated, safely, by multiple LPARs concurrently. Individual files cannot
be, but z/OS has methods than can ensure that need not happen (OK, the
programmer can get around it, but woe unto him who does it!).

I'm going to ASSuME that it is more like UNIX. The DASD is not shared,
but a program on one system can do a database call to read or maybe even
update a database on a different system. I will also assume that the
SPOOL is not sharable. Yes, we do that. Users on the development LPAR
can watch jobs on the Production system as they run and view their SPOOL
files both as the jobs run and after the fact.

LPAR concepts:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rz
ait/rzaitconceptoverview.htm

As far as separate but shared....perhaps multiple DBs on a single
system might be of some use?
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rz
ahf/rzahfworkwithmultipledb.htm

It's a relitivly new feature, prior to its availablity a large shop
might have 3 separate machines (or LPARS) for Dev/Qa/Pdn. While a
small shop might simply use three separate sets of libraries
(schemas).

HTH,
Charles

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)
Administrative Services Group
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mckown@xxxxxxxxxxxxxxxxx * www.HealthMarkets.com

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential or proprietary information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.





--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.