Lee,
To use Debug to monitor a process:
1) First find the PIN of the process with SHOWPROC
2) Use DEBUG, first enter PIN #(the pin number from showproc), then TRACE
3) Repeat the TRACE command

Other macros are available but this is a good start. The trace should show
which intrinsics are responsible.
One possibility is the pathing of the discs. It is common to find SCSI
bandwidth problems due to too many devices on a single path.

Another thing that could have happened is that in the past you may have
previously placed master entries using ADAGER on a capacity change. ADAGER
will place the primaries first then seed the secondaries in an attempt to
provide 'empty holes' to prevent clustering. I don't think that SUPERTOOL
does this. Thus you could have a clustering problem that you didn't have
before. HOWMESSY, or DBLOADNG could shed some light on this. We also have a
tool that is more MPE/ix friendly to analyze these situations. I can send
you a copy if you would like.

Mike Hornsby
[log in to unmask]
 (513) 922-0509 - Fax (513) 347-2834
Disclaimers: This communication is intended for the general use "AS IS",
with no written or implied warranty. It does not represent any corporate
views or disclose any private data or information. The sender has made every
effort to attribute authors of any included materials. Reference to any
commercial products, process, or service does not necessarily constitute or
imply its endorsement or recommendation. This communication and the
obligations of the parties hereunder shall be interpreted, construed, and
enforced in accordance with the laws of the State of Ohio, excluding
principals of conflict of laws.

-----Original Message-----
From: Lee Gunter <[log in to unmask]>
To: [log in to unmask] <[log in to unmask]>
Date: Wednesday, December 10, 1997 3:17 AM
Subject: Control block waits -- increased drastically


>Greetings,
>Recently, we installed the first of three phases of our Y2K conversion
>project.  Since then, the system (996-500) has seen very erratic
>performance -- particularly among some specific batch and online processes.
>Glance/iX is reporting these processes of interest primarily IMPeded, with
>the process detail screen showing a control block wait.  My understanding
>of control block waits leads me to believe that a locking contention
>problem exists; however, according to our programmers, no locking code was
>changed.  As soon as we suspend contending jobs and allow them to complete
>one at a time, the problem disappears.
>
>To prepare for the conversion and provide sufficient workspace, we added
>additional 4GB volumes to the two user volume sets on which the converted
>databases reside, and we balanced the sets using Bradmark's "Disk Space
>Manager" product's 'MANAGESET' command.  All disk volumes are of identical
>size on both sets.  During the conversion, data was unloaded serially from
>the affected datasets to flat files, converted in place, the datasets were
>erased, then the data was loaded back using SUPRTOOL.  No intervening sorts
>were applied to the files prior to reloading the converted datasets.
>Interestingly, some processes which block on control waits are accessing
>files/datasets not touched during the conversion and, in some cases,
>residing on different volume sets from those which were converted.
>
>We're attempting to analyze the system's performance logs from before and
>after the conversion to see, 1) if this situation existed but has become
>worse, or 2) if this is truly a new problem.  LaserRx has chosen this week
>to start misbehaving, so progress is slow; therefore, I come to the gurus
>on the list to help point me in a sensible direction to try to solve this.
>I have little to no experience with DEBUG, so I'm unable to track by any
>means I know where the programs are spending their time.  What little hair
>I have left on my head is much grayer and almost gone.  :-<
>
>Please feel free to contact me privately, if you wish.
>TIA,
>
>Lee Gunter
>Regence Blue Cross Blue Shield of Oregon / Regence HMO Oregon
>
>mailto:[log in to unmask]
>voice...503-375-4498    fax.....503-375-4401
>==========================================================
>The opinions expressed, here, are mine and mine alone, and do not
>necessarily reflect those of my employer.
>
>