Lee writes:

> 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.  :-<

Two suggestions:

   1) SPT/iX ... a product of HP.  SPT/iX is sort of an "NM SAMPLER", if you
      remember SAMPLER on MPE V.  It's a program that can monitor a process
      and give you a breakdown of where it's spending its time.

   2) Debug/iX.  Several posters have noted how to look at a process.
      Note that Pete's suggestion of combining the "PIN" and "TR" command
      on a single line is a good one ... the "PIN nnn" command takes a
      *snapshot* of the registers of the process.  Those registers, and
      the stack environment change rapidly.  You want to minimize the time
      between getting the snapshot and using it (via the TR command).

      An alternative method of using Debug is to run debug from the environment
      of the process itself.  If you can't just "run ..;debug" an alternative
      (which requires PM) is to "capture" the process into debug.

      The basic method of doing this is:

         a) determine PIN of process

         b) from a PM user logon, enter Debug

         c) if the process you wish to debug is part of a batch job then

              i) enter: env job_debug true

              ii) tie up LDEV 20.   (I often do a ":PAUSE 120")
                  (You don't want the CI (or any other program) doing a read from
                  ldev 20 for awhile)

         d) using "PIN nnn; TR", find a spot in the target process that
            you can put a breakpoint at.  Ideally, an intrinsic entry point
            is the best spot.  Without going into lengthy details, avoid
            putting a breakpoint at any code address beginning with "a."
            unless the name is "?" followed by an intrinsic name.

            E.g.:    b FREAD
            Note: the above is equivalent to:  b FREAD:nnn
            (where nnn is the PIN) because you've earlier done a "PIN nnn"
            command)

         f) the process will enter Debug as soon as it hits the breakpoint.

            If it was in a batch job, Debug (from the process environment) will
            be interacting with ldev 20.  Otherwise, it will be interacting with
            the terminal of the session the process is in.

Note: the "capture" a process into Debug requires PM and is potentially dangerous.
If, however, you confine the breakpoint to a code address in the program or to
the entry of an intrinsic (e.g.: FREAD), you should be sage.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html