Good Morning Jerry

These are just some thinking points as your dasd person may have to get
some detailed status from the dasd boxes to help confirm or disprove
these thoughts.

I have not worked with the stk boxes, as we have the emc type here and
have vm not mvs driving them. With vm we had the os doing caching along
with the caching done on the raid box. But the emc box does not do the
virtual raid work (comprssion) that the stk boxes do.

With the emc boxes the i/o times to the stk would get long since the os
was doing read ahead and would do whole track reads and writes.


You might want to look at the size of the i/o for the storage groups
and see the i/o sizes are much larger then your average system i/o's
If so then the longer i/o are not such a bad thing.

The raid units get their speed when the application can use the raid
cache for most of it's reads and writes. With the stk you also have
the added factor that the unit compresses the host data on write and
decompresses it on read.This reduces the amount of data that has to
be read and written on the raid dasd (disk) units.

So the adsm storage pool maintenace function are going to hurt the stk
status in too ways. First the adsm data most likey is compressed by the
client, so the stk unit cannot compress it down like most of the other
host data. The other thing is that it is going to write alot of data to
the stk cache, which then has to be written to the raid dasd units.
Once the stk cache or the adsm task's cache quota are filled, then
the i/o is going to have to wait for the raid dasd (disk) i/o to finish.
This most likely is your reason for your long disconnect times.
I suspect that sequential blocks of data from the host's view are not
sequential on the stk dasd (disks). If the dasd space on the stk is
tight then this might also might lengthen the time needed to find the
space needed to store the data.


I suspect that the data base I/O are not as bad since they compress
better.  Also a large number of the data base i/o would be canceled
due to large db buffers defined in adsm.
-------------------------------------------------------------------------
Leonard Boyle                               snolen AT vm.sas DOT com
Leonard Boyle                               snolen AT vm.sas DOT com
SAS Institute Inc.                          ussas4hs@ibmmail
Room RB448                                  len.boyle AT sas DOT com
1 SAS Campus Drive                        (919) 677-8000 ext 6241
Cary NC 27513