Me and many other technicians hate the limitation that the only supported way of migrating the Loadsource disk to a smaller LUN is save/restore IBMi OS. With the method described below, I was able to copy the Loadsource to the smaller disk, and it worked. First of all, the credit about this solution goes to Severin Romanov. He was the first technician who discovered and share the information. I’ve performed successfully the procedure on my test system, and decided to share it.
Secondly, this procedure is not supported, and not advised by IBM. You do it on own risk! It might or might not work. Update Aug 2020 – IBM documented this process exactly as in this post, thus they decided to share this process to the public. If someone wants to follow IBM procedure here is the link
Always make sure that you have a tested backup which you can use in emergency situation. The good part part is that there is no ‘darknet’ commands involved. It is all about to perform set of system commands to achieve a goal.
If you ask me for advise – “go for it” the risk is low. In the worst case, you are going to waste few hours of work, 2-3 systems IPLs , and the procedure will not work (this is very likely why IBM does not support it). If you do it on the production node, where no room for outage is allowed, then create a flashcopy in order to perform a quick restore if something goes horribly wrong.
The system has 3xLUNs, the loadsource disk is 71Gb big, and I’m trying to replace by 40Gb LUN. As you can see below, the copy operation resulted in error. The smaller disk is not eligible to be a new loadsource which is reported as no target disk. I performed this exercise on a test system running V7R3.
The procedure is designed for V7R2 upwards.
Luckily the limitation (coping to equal or bigger disk) is not coming from the disk size but from the ‘fingerprint’ (offset) where the data being stored. In order to copy the data from a bigger to a smaller volume we need to reduce the amount of data stored on volume 1, and force the system to reallocate the offset. The new disk must deliver the same offset where the last data chunk being stored on the original volume. If this is achieved, the regular DST menu should offer a copy option. So, how to reduce the offset and how it can be checked?
Let’s start from the begging, IBMi OS by default tries to utilize each disk within the ASP at the same ratio. That is why volume number 1 beside storing the LIC code contains some other data. Command WRKDSKSTS shows usage of each disk. Using DUMPFSMAPINFO macro in SST, you can find much more information.
- STRSST.
- Start a service tool
- Display/Alter/Dump
- Display/Alter storage
- Licensed Internal Code (LIC) data
- Advanced analysis
- Type DUMPFSMAPINFO,
- In macro options type in : -d 1
In the example 71Gb LUN being used, 44,36Gb is free (LUN was occupied only about 30% ), but more important is the High Water Mark (2nd screen), this is the offset (area) used for storing data on this particular volume. Therefore, if we could move unwanted data and leave the LIC only, the offset should be reduced. If the new ‘smaller’ disk would offer the same address, the copy loadsource operation should be possible. In order to squeeze the data do following:
- Stop allocation on the LS disk:
STRASPBAL TYPE(*ENDALC) UNIT(1)
2. Initiate a data move to remaining volumes.
STRASPBAL TYPE(*MOVDTA)
This is time consuming operation. CHKASPBAL command can be used for checking or WRKSYSACT if any tasks with following name is active: SMIOCOLLECT, SMTRCTASK, SMDASDUTILTASK, SMBALUNIT, SMEQ.
3.Change IPL atribute and IPL the system when possible
CHGIPLA CPRJOBTBL(*NEXT)
The IPL is necessary, STRASPBAL do not move all data which could be moved. For instance, temporary objects or objects that are currently being used or pinned in main storage can’t be moved. Furthermore, I’m not sure if the offset can be reduced on the active disk, thus we need an IPL.
The reboot can take some time, depending on JobTable. Once the machine comes back, the size of the LS disk should be already reduced. You can run DUMPFSMAPINFO macro and see if the offset gets reduced.
4. Initiate a data move again
STRASPBAL TYPE(*MOVDTA)
5. Once the move gets completed. IPL the system in the manual mode, and start DST.
Start the drums now, this is a big moment….. Either you wasted the time or data got shrink and the Copy disk unit data menu in the DST offers coping data to a (smaller) disk.
If you are lucky, the data being copied, the process takes some time and results with one more IPL, removing the original disk from ASP configuration.
Good luck!
Do not forget that there must be one un-configured LUN attached to the system. The minimum size depends on the storage. Details can be found here V7R2 and V7R3
IBMi.org - Bart's blog 