Re: New 270.

Andy Nolen-Parkhouse wrote:

> Jenny,
>
> The easiest way to check the activity on your disk arms is to use the
> WRKDSKSTS display.  Pick a time which represents your peak load and
> execute the command.  This will present an interactive status display.
> Wait about half a minute, then refresh the statistics (F5).  One of the
> columns will give the per cent busy.  Figure that forty per cent is the
> maximum amount of activity which the system can tolerate before disk
> arms become a limiting factor on overall performance.  If you're below
> twenty on all of your drives then you're in good shape.
>
> If you see a consistent disproportionate amount of activity on one or
> two drives, then you might benefit from balancing your data using the
> ASPBAL commands with the *USAGE parameters.  You should expect your
> larger drives to have activity which is proportionate to their relative
> size.  Given that an 8 GB drive will have twice the amount of stuff on
> it as a 4 GB drive, it stands to reason that a given bit of data
> required by a program is twice as likely to be on that drive and it
> should see more activity.  This is not a problem; this is the way the
> system is designed.  I don't know if the ASPBAL commands will compensate
> for differing volume sizes.
>

Hi,

This sounds like the method we used to identify the 'work control block table'
problem under V3R1M0. Remember when some whizz-kid decided to put the whole
table on one disk?  It used to kill the performance on the system once you had
more than 16000 jobs in the system (not on!!!) We were  deleting spool files
and reducing obsolete jobs at a tremendous rate (manually)/ The WHOLE control
block table was on one disk. I recall that the size was 16000 jobs. Every
increment created a new table (member). Whenever you performed ANY activity
relating to a job, the system suffered: wrkusrjob, chgjob, wrkactjob, etc.

Cheers.

Jan.