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

-----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.