Most AS/400 and iSeries boxes have multiple disk units. Some machines, like the one that I work on, have not only multiple disk units but also multiple types of disk units. Since the AS/400 and iSeries hardware uses a scatter load algorithm to physically populate the disk, are you sure that your disk has data optimized for maximum performance for retrieval from those disk units? This article describes both the reasons and the how-to on disk balancing.

The scatter load algorithm tells the system to spread objects over most or all of your physical disk units. For example, your customer master file may physically exist on many different platters; one disk unit may hold pieces of many different objects. When requests come from the disk controllers, efficient retrieval of that data depends on both where the data resides and how many times that data is accessed. To get optimum access performance from your disk, you need to control where that data lies on a disk and, possibly, which disk it lies on.

Balance the Disk by Capacity Only

Recently, I was fortunate to be able to add disk to my AS/400. The disk types that were originally installed on this particular AS/400 were the 4 GB (Model 6607) variety, and I added six 8 GB (Model 6717) units. In the planning stage, I contemplated separate auxiliary storage pools (ASPs) for journal receivers, and how to put my less-used data (such as a test database) on the slower disk while keeping my more frequently used data (such as a live database) on the faster disk. Trying to monitor this type of data would be an insurmountable task for anyone. Thankfully, OS/400 was able to handle this arduous task.

After the IBM Customer Engineer (CE) installed the new disk units, I knew that over time the OS/400, with the aid of commands such as Reorganize Physical Files (RGZPFM), would equally distribute the data amongst all of the disk units. However, I wanted to be able to do the distribution instantly after the disk was added and without the task of saving, initializing the disk, and restoring all of my data. As data is loaded fresh from a tape or optical device, the system will efficiently place that data over all disk platters. Using the Start ASP Balancing (STRASPBAL) command, the task of distributing that data was easily accomplished in just over an hour. Because the CE had just installed the new disk units, the system was essentially in a dedicated mode. However, a dedicated box is not required for STRASPBAL. Keep in mind that performance on your system will be

affected by multiple tasks requesting I/O from the disk while running STRASPBAL, so make sure you run the command during off hours.

Running STRASPBAL requires only that you have All Object (*ALLOBJ) authority. Before I started the balance, I ran a Work With Disk Status (WRKDSKSTS) command and did a print screen to get a baseline. WRKDSKSTS will show you what is on each disk unit (Figure 1). Lastly, from a command line, I ran this command:

STRASPBAL TYPE(*USAGE) ASP(1) TIMLMT(60)

The TYPE(*USAGE) keyword told the system to balance the system according to the physical amount of used and free space on the disk. You will also need to tell the command which ASP to balance. I have one ASP, so that was easy. If you have multiple ASPs, the command will balance all ASPs with ASP(*ALL) (Figure 2). The last parameter is the time limit for the balancing to run, expressed in minutes. For those who are blessed with enough resources, you can use *NOMAX. This will allow the balancing to run to completion regardless of the time it takes. Otherwise, use whatever amount of time you can spare in your shop.

How I Did It

I allowed STRASPBAL to run (it does go to batch should you call it up interactively) for those 60 minutes. The processor light continued to flash for the entire 60 minutes. At the end of the time period, I looked at the disk statistics again to find out that the disks were not completely balanced. I ran the command again but just for 10 minutes. Checking the disk statistics again with WRKDSKSTS, each unit was almost perfectly balanced. Mission accomplished—and it wasn’t mission impossible!

Estimating the amount of time you will need will vary, depending upon the speed of the processor, the type of disk you have, the amount of data you have on the disks, and the number of disks you will be balancing.

Spreading Data by Usage

After running the STRASPBAL command, I was satisfied that the data was spread evenly across both the old and the new disk units. However, since the 8 GB disk units have better performance than the 4 GB units, I wanted the most frequently used data to physically stay on the 8 GB disk. How could I ensure that? I could have used separate ASPs, ensured that my journal receivers were all in one ASP on the slower 4 GB disk, and moved the test database and source libraries to the slower ASP.

Fortunately, IBM has increased the access speed on newer disk units so that no manual or user intervention is needed. For years, performance tuning gurus have told us to put journal receivers in a separate ASP. Writing entries to journal receivers takes a lot of overhead to perform. Creating separate ASPs would alleviate this overhead. I often wondered why the system could not handle that task for me. Today, the system does handle this task and we don’t have to concern ourselves with tasks that the system will handle.

OS/400 comes complete with the tools that allow you to perform the task of moving data, for efficient retrieval, with only two commands. Along with STRASPBAL, there is another command, Trace ASP Balance (TRCASPBAL), which will collect the usage statistics for the disk. The first step is to collect these statistics so that the balancing will be able to move the more frequently used pieces of data to the faster disk and even manipulate the location of this data for faster access. To begin collecting these statistics, I ran the TRCASPBAL command:

TRCASPBAL ASP(1) SET(*ON) TIMLMT(540)

The ASP has an identical meaning, as in the STRASPBAL command. The Set keyword turns the data collection either On or Off (*OFF). The time limit tells the command how long to collect data. I chose 540 minutes, or nine hours. This was the prime usage time for my shop. Again, *ALLOBJ authority is required in the user profile of the person running this command. You can also turn the collection off at any time by calling the command again with the keyword SET(*OFF).

After the time limit had expired, I ran the STRASPBAL command again but with different parameters. Instead of using the Balance Type *CAPACITY option, this time I used the Balance Type *HSM, or Hierarchical Storage Management option. *HSM will do two things: It will place the more frequently used data on the disk so that it will be retrieved earlier than the less-used data, and it will use faster access disk units to hold the more frequently used data and leave the less-used data on slower access disks. For *HSM, the system must have the statistics available from the TRCASPBAL command. STRASPBAL, with either the *HSM or the *USAGE keywords, resets all statistics captured by TRCASPBAL.

Balancing in Your Shop Is EZ

By using the Work with Job Schedule Entries (WRK-JOBSCDE) command, which I wrote about in “The Case of Duplicated Work” (MC, June 1998), and a little bit of smarts about peak and slow times in my shop, I schedule the job to gather disk statistics (TRCASPBAL) to start about 8:30 a.m. and allow it to run for nine hours. That schedule covers the peak times for my system. After things begin to slow down at night, I schedule the actual balancing to run for an hour. I chose an hour squeezed between the time the nightly batch processing starts and the daily interactive processing ends. By doing this during the workweek, I continue to balance the disk in the most efficient manner for my shop, both physically on the disk and by using the faster access disk units. The best thing is that I set up the balancing once, and, except for the completion messages, I don’t have to worry about it again.

You will need to decide the correct times for your shop, and that may take some trial and error. Achieving maximum performance from your disk is as easy as two job scheduled entries or a prestart job start entry on a subsystem. After all, what is the slowest part of any computer? Disk I/O. Minimize that bottleneck on your system today by balancing your disk.

REFERENCES AND RELATED MATERIALS

• IBM Information Center: http://publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/info/index.htm

• ”The Case of Duplicated Work,” Tim Johnston, MC, June 1998

Figure 1: Using the WRKDSKSTS command can help you see the results of system balancing.

Figure 2: Use the STRASPBAL command to spread data evenly across your disk units.