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