Re: TRCASPBAL and STRASPBAL does not seem to work

Which disks are the ones you notice to be "used more than others" ?
Please give more info on your exact disk/controller configuration.
At first sight it looks a little strange to me ...

I see that disk 2-9 must be on the same controller in a RAID-config
in an "eight-disk-set", the next 4 disks (10-13) are in a "four-disk-set"
the next two disks have obviously been added to that set afterwards
and No. 24  disk is completely out of that order ...
Disks 16-23 and No.1 seem to be on the next controller in an
"eight-disk-set" of another RAID-array, but how are they spreaded
over the system busses / controllers, that's the question ...

At first sight I would say that the 9th 8 GB disk is some kind of "extra"
and that there is one 6607 disk lacking to make the bunch of eight disks
for that second RAID-set complete.

Second tip is to identify the data (-library) which is used the most, then save 
it
to tape, completely delete that library (or files) and run STRASPBAL with
*capacity as parameter, then do a restore of your data files.
This should spread your data over more arms than before.

But, for more performance tips, we definitely need more info.

Regards from Germany, Philipp Rusch

"Mark A. Manske" schrieb:

> I have a few disks on a 820 at V5R1 that are being used much more
> heavily than most others, thus hampering performance.
>
> I had run the TRCASPBAL for a week to collect data, then we
> IPL'd and I had set things up in the startup to do the STRASPBAL,
> it ran for 1 second - and did nothing.
>
> I looked through the archives, and on IBM's manuals which dragged me
> to the Hierarchical Storage Management manual -
>
> None of which told me anything I did not already know, I am wondering
> how the following commands "appear" to have done nothing -
> note, these ran under QSECOFR user, and shows in the QHST log
> that the ASP trace started, there is no log entry showing that it ended...
>
> On 11/23/2002 I ran the following command-
>
> TRCASPBAL  ASP(*ALL) SET(*ON) TIMLMT(9999)
>
> and the next Saturday I ran the following command -
>
> STRASPBAL  ASP(*ALL) TYPE(*USAGE) TIMLMT(1800)
>
> I set a time limit of 1800 so as to allow time to let system settle down
> before the Sunday shift started working.
>
> Due to budget constraints and sporadic growth, we have a varied
> collection of disk packs - as follows:
>
>               Size
>  Unit  Type    (M)
>     1  6717   6442
>     2  6607   3670
>     3  6607   3670
>     4  6607   3670
>     5  6607   3670
>     6  6607   3670
>     7  6607   3670
>     8  6607   3670
>     9  6607   3670
>    10  6607   3145
>    11  6607   3145
>    12  6607   3145
>    13  6607   3145
>    14  6607   4194
>    15  6607   4194
>    16  6713   6442
>    17  6713   6442
>    18  6713   6442
>    19  6713   6442
>    20  6713   8589
>    21  6717   6442
>    22  6717   6442
>    23  6717   6442
>    24  6607   4194
>
> Any thoughts as to why this did not work for me "as expected" -
> I was hoping to balance the work load of the heads/packs; some run at 0% to
> 5%,
> and just five to six will run at 70%-90% during many runs that we have going
> in
> batch all this while the CPU utilization is at 40% or less.
>
> TIA
>
> Mark A. Manske
> Fleming CSD - Plymouth Division
> Sr. Project Lead
> Phone      (763) 545-3700 extension 273
> Web Site  http://www.minter-weisman.com
> E-Mail      mailto:mmanske@minter-weisman.com
>