Thanks, some great suggestions that I hadn't thought of. I'm going to spend 2 weeks in the Benchmark Center testing before doing it in production so hopefully we'll come out of there with a solid plan.
Paul Fenstermacher
Certified Specialist - i5 System Administration
Bass Pro Shops
417-873-5424 d
417-429-7694 c
paulf@xxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Jones
Sent: Friday, November 06, 2009 9:19 AM
To: Midrange Systems Technical Discussion
Subject: Re: Consolidating partitions
You probably won't find checklists since the process of merging partitions
is highly dependent on the applications being run and how they have been
configured.
30,000 foot view ..
For each LPAR, lock down the security as tightly as possible. Make sure the
users in each can only access their apps/data. Once you merge, you don't
want users to be able to access data from the partition they previously did
not have access to.
Look for conflicts. Look everywhere. System values, distribution
directory, non-IBM user ID overlap, for that matter changes to IBM user IDs,
special subsystem descriptions, overlapping library names, system & user
library lists, WebSphere & HTTP instances, IFS directories, etc.
Document everything you discover. Something that describes the source
setting, target setting, post-merge setting, and reason for any changes.
This is not only a checklist for what to do when performing the actual merge
but is also your main troubleshooting doc should things go wrong.
Mitigate any differences in network configurations.
Make sure both LPARs are on the same OS & PTF levels. Also make sure the
target LPAR has every LPP that will be needed.
Make sure any servers or workstations that access data on the LPARs can see
both. Ditto for any outside interaction - FTP scripts, web services, EDI,
etc.
Once you're confident that merging the LPARs won't cause problems, you're
ready to start testing & planning the actual migration.
The actual migration would be something like:
Save the target LPAR so you can back out if needed.
Save/restore the stuff to merge from the source LPAR.
Update system values and mitigate everything you uncovered during the
conflict discovery.
Update DNS records/IP config.
Update clients to use new server. Also update and scripts etc.
Test everything you can think of WRT the apps & connectivity from both the
source & target LPARs. Fix any problems that come up.
Do another save on the target LPAR before turning it over to the users.
This can be a save-changed-objects or a NONSYS if you don't have time for a
full save.
On Fri, Nov 6, 2009 at 8:30 AM, Paul E. Fenstermacher <paulf@xxxxxxxxxxx>wrote:
I have a project to move everything in partition A to partition B but I
can't find hints or checklists anywhere. Has anyone done this? Thanks.
Paul Fenstermacher
Certified Specialist - i5 System Administration
Bass Pro Shops
417-873-5424 d
417-429-7694 c
paulf@xxxxxxxxxxx <mailto:paulf@xxxxxxxxxxx>
--
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
