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

IASPs since V5R2 are really very cool - kind of a mini-LPAR. You carve out the arms you want to dedicate to one. Varying it on is like an IPL. You get another QSYS.LIB under an IFS directory with the name of the IASP.

You are able to associate your job with only one IASP at a time, using the SETASPGRP command. But you can dissociate your job from it and associate with another with the same command run twice.

You can't have the same library names inside an IASP that you have in SYSBAS - your library name space is a combination of the two - system catalogs get their own name, I believe.

So you can't have a live environment in SYSBAS and a test of the same name in an IASP - both live and test have to be in IASPs. So you have to figure how much DASD you need for each environment.

Still, very cool for testing, and you don't need a lot of extra hardware, as you might with separate LPARs.

There are some object types you can't have in an IASP, last I saw - JOBQs and such, IIRC.

It IS possible to copy objects between IASPs, even those that are not currently attached to your job - there are all those extra parameters now on several commands. Not CPYF, at least at V5R3, but CRTDUPOBJ can.

Enough!

Later
Vern

Jerry Adams wrote:

Again, you're right, Dan; your response was more in line with the OP's scenario. And, as others pointed out, I missed the iASP method, but that's not something that I have ever used.

You know, that's one (of many) thing that I like about this system: There's more than one way to skin that cat. And the List members who freely share their knowledge and perspectives.

Thanks.

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Monday, December 08, 2008 2:23 PM
To: Midrange Systems Technical Discussion
Subject: RE: YAIQ - Yet another ignorant question: multiple LPARs.

I agree, multiple LPAR's are best for test and development. No way to
share user profiles between them, however. I was trying to offer a
configuration similar to what OP described in his z environment. RACF is
the z security system and is housed in a database. i security doesn't
use a database, at least not a database that can be shared. i security
uses *USRPRF objects and system level stuff to authenticate against that
profile. On top of that, the system level stuff must have access to both
the user profile object and any object to be used in order to authorize
the user to the object. Those objects might include programs, database
files, data areas, outqueues, print files, everything.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jerry Adams
Sent: Monday, December 08, 2008 12:45 PM
To: Midrange Systems Technical Discussion
Subject: RE: YAIQ - Yet another ignorant question: multiple LPARs.

This is, as you say, Dan, a sometimes useful method. In fact, when you
have only one system (LPAR) it's about the only way you can go. And I
have had to do this myself in other environments.

However, multiple boxes or LPAR's (take your pick) have the distinct
advantage of being able to fully test fixes, conversions, etc. For
example, I just finished testing our year-end processes on a backup box.
Part of the process is to copy the history from a library named HISTORY
(how odd) to one named HIST2008 and clear all of the tables in HISTORY.
While one could do this one a single LPAR/box by using pseudonyms for
the libraries and, then, changing them back to production names (hoping
one didn't make a typo - for which I am notorious), it sure is nice the
have that separate box to test things with production data, programs,
etc.
Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Monday, December 08, 2008 10:42 AM
To: Midrange Systems Technical Discussion
Subject: RE: YAIQ - Yet another ignorant question: multiple LPARs.

John,

What you're describing is best handled on i with a single LPAR, multiple
interactive sub-systems, and multiple library objects. Workstations are
assigned to sub-systems by id ranges and assigned a job description and
library list when they are signed on. Programs and data will be found in
libraries through the library lists. This is the only way you're going
to be able to share your security info (RACF) between the multiple
subsystems. You can use group profiles to secure the libraries to keep
one set of users out of the other set's programs and data. In fact, you
only need the subsystems to handle allocation of memory and cpu.

Dan Kimmel

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of McKown, John
Sent: Monday, December 08, 2008 8:20 AM
To: Midrange Systems Technical Discussion
Subject: 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: Sunday, December 07, 2008 11:16 PM
To: Midrange Systems Technical Discussion
Subject: 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

You've hit it on the head. And, to be honest, if it is not possible, I
will be very glad. I really __hate__ this sharing. As far as I'm
concerned (security/auditor hat on) it is just an easy way to corrupt
data or get the wrong data into an environment. But I'm not allowed to
fix it on the z. So, it is cannot be done on the i, I will get what I
want!

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

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