My favorite technique is to move the data (except load source) using the
*ENDALC and *MOVDTA technique. Then use DST to copy the load source. Cuts
the down time by quite a bit.

The second option if possible (same vendor for the storage?) is to simply
have the storage arrays replicate all the LUNS over to the new array. Once
that's done, simply change the zoning on the fibre network to point at the
new storage and bring it up.

Physically moving a LUN is simply not possible in a SAN since like IBM i,
you really don't know (or care) where the data really is.

Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Mitchell, Dana via MIDRANGE-L
Sent: Thursday, January 23, 2020 12:44 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Mitchell, Dana <dmitche@xxxxxxxxxx>
Subject: Moving all systems to new external storage subsystems

Currently all of our i lpars are running on external storage behind 2 VIOs
in each box and we need to migrate to new external storage subsystems. A
while back I opened a PMR to IBM asking about migrating the load source and
there was a short discussion here about this kc article:

Is there a different kc article that addresses doing this with external
storage? This one has a step:

Move the replacement disk unit.
1. Move the replacement disk unit that contains the load source
information into the slot where the old load source disk unit (unit 1)
originally resided.

Isn't that sort of a moot point since all the ldevs are vio hosted on
external storage? Perhaps just need to update the Tagged IO to the new
adapter that the new load source is attached to?

Also, is there a kc article that outlines moving all of the non-load source
volumes? Or is there nothing more to it than STRASPBAL *ENDALC and


Attention: This electronic document and associated attachments (if any) may
contain confidential information of the sender (SHAZAM Network) and is
intended solely for use by the addressee(s). Review by unintended
individuals is prohibited. If you are not the intended recipient: (i) do not
read, transmit, copy, disclose, store, or utilize this communication in any
manner; (ii) please reply to the sender immediately, state that you received
it in error and permanently delete this message and any attachment(s) from
your computer and destroy the material in its entirety if in hard copy
format. If you are the intended recipient, please use discretion in any
email reply to ensure that you do not send confidential information as we
cannot secure it through this medium. By responding to us through internet
e-mail, you agree to hold SHAZAM, Inc. and all affiliated companies harmless
for any unintentional dissemination of information contained in your
message. Thank you.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.