That is an absolutely valid way to do it, and it has its advantages.

But, if you are hosting customers all over the globe, scheduling maintenance windows can become a nightmare. Customer X can allow an outage in the middle of the night, but customer y is getting started with their work day at that time. Then customer z runs 2 shifts that overlap both previous customers.

Not arguing, just food for thought.


Brian May
IBM i Modernization Specialist
Profound Logic Software
937-439-7925 Phone
877-224-7768 Toll Free

Modernization Made Easy!

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, June 10, 2014 10:55 AM
To: Midrange Systems Technical Discussion
Subject: Re: Why do companies partition their Power Servers?

I myself would love to have a completely isolated test partition
where I can use library lists that are exactly the same as
production library lists, user profiles secured the exact same way
as production user profiles, and so on.

I agree that partitions are a viable solution for that. Just save data and configurations on one partition and restore them to the other. But I don't think that partitions are the best solution.

We never hard code library names in program code, except for temporary overrides to QTEMP - or such. We always manage Library Lists through configuration files and occasionally via traditional *JOBD objects. Library names are always soft-coded and easily maintainable so that authorized users might point "applications" to libraries that they are authorized to.

We recently configured 180 new IBM i subsystems, 60 new HTTP server instances, 60 new instances of our Web portal, and 60 new sets of Libraries, for 60 separate state agencies, to enable each to run "isolated"
environments on a single IBM i partition. Each agency manages their own users, user groups, user authorities in configuration files in separate libraries and IFS directories.

I believe it will be much easier to to manage 60 such soft-coded environments than 60 LPARS.

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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page