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

["Charles Wilt" <charles.wilt@xxxxxxxxx>]

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.