Troubleshooting
Problem
This document provides information about moving data off disks in preparation of removing the disks from the ASP.
Resolving The Problem
If you are planning to remove disk drives from your ASP configuration and want to reduce the down time associated with removing drives using DST, you can begin by stopping new data from being written to the selected disk units and move data off those disks. This can be done using the STRASPBAL command while the system is up and running.
Notes:
1. The *ENDALC and *MOVDTA options are available in R520 and newer releases.
2. Starting at R710, drives can now be removed from an ASP using SST instead of using the procedure in this document; refer to document 720735, Remove Disk Units From ASP Using SST.
Notes:
1. The *ENDALC and *MOVDTA options are available in R520 and newer releases.
2. Starting at R710, drives can now be removed from an ASP using SST instead of using the procedure in this document; refer to document 720735, Remove Disk Units From ASP Using SST.
Performance vs. Speed:
Removing disk units from an ASP (including moving data off to other remaining units in the ASP) is fastest when performed in Dedicated Service Tools (DST). Unfortunately, the system is completely unavailable for any other work during this time. If speed of the removal is not important, but keeping the system available for production work is, System Service Tools (SST) can be used to remove the drives with minimal performance impact. However, SST may take a long time to remove the units. Between these two extremes, you can use STRASPBAL to drain as much data as possible before completing the remove with either DST or SST. With STRASPBAL, you also have some limited performance/speed adjustment by setting the PRIORITY parameter to *LOW, *MEDIUM, or *HIGH.
To use STRASPBAL to drain data before removal, you should do the following:
Step 1: On the operating system command line, type the following:
STRASPBAL *ENDALC
Press the F4 key to prompt the command. The screen will look similar to the following:
Start ASP Balance (STRASPBAL) Type choices, press Enter. Balance type . . . . . . . . . . > *ENDALC *CAPACITY, *USAGE, *HSM... Storage unit . . . . . . . . . . ___________ Number + for more values ___________ Bottom F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys |
Type the disk unit numbers in the Storage unit field and press the Enter key. This stops new data from being written to the selected disk units.
Step 2: On the operating system command line, type the following:
STRASPBAL *MOVDTA
and press the F4 key to prompt the command. The screen will look similar to the following:
Start ASP Balance (STRASPBAL) Type choices, press Enter. Balance type . . . . . . . . . . > *MOVDTA *CAPACITY, *USAGE, *HSM... Time limit . . . . . . . . . . . ___________ 1-9999 minutes, *NOMAX Bottom F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys |
Type a Time Limit for this procedure to run. It is suggested that you use *NOMAX so the maximum amount of data is moved off the disks.
There are some types of data that cannot be moved with this command. It is common for the disks not to drop to 0% used.
Note: For R520, journal data is not moved by the STRASPBAL command. R530 and higher will move journal data.
Step 3: After STRASPBAL has completed, the drives are ready to be removed from the ASP configuration during a manual IPL by using DST. Or use SST if the system is at V7R1 or later - see document 720735, Remove Disk Units From ASP Using SST.
Note: As long as any disk units are marked for *ENDALC, the drives in the ASP typically appear unbalanced.
For additional information, refer to document 644689, Operating System Disk Balancing Support.
[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0"}]
Historical Number
390398321
Was this topic helpful?
Document Information
Modified date:
17 May 2022
UID
nas8N1019072