Re: Debug anomaly

Rob,

The user is not listed individually, there are no private
authorities to these programs. The program state is
*USER. The weird thing is that I can debug the program
by adding it to debug with F14 - option 1, but I can't
specify the program directly. Because of this, I can debug
the program (change variables, etc.). I believe that when
my group profile is set to the owner of a program I should
be able to debug the program.

I can debug a service program with identical authority.
It looks like the validation of a service program happens
in a different program. If I trace the job it looks like a
service program is essentially added to debug after
starting debug. Adding a program or service program
works as I would expect and I think that is why I can
debug service programs but not programs.

The program sending the error is QTECADPG for a
program. It sends CPF1910. If I am not authorized to
a service program QLIROHDL sends CPF9802.

I do have a clue from my testing. Debug also appears
to do some profile checking at run time.  I have not
seen this documented. The security reference says
that you need authority to the following:

STRDBG Program 2 *CHANGE *EXECUTE
Source file 4 *USE *EXECUTE
Any include files 4 *USE *EXECUTE
Source debug program *USE *EXECUTE
Unmonitored message program *USE *EXECUTE

Here is something that I think is strange. I can be
running a job with an effective user that should
allow me to debug a program. I can try debug and
it doesn't work (without the F14 workaround). I can
then change the profile while the job is running to
set the group from *NONE to the group profile that
owns the object. Then debug works.

David Morris

>>> rob@dekko.com 03/15/02 06:48AM >>>

Is the user trying to debug the program listed individually in the
dspobjaut?  If so that will override the group.

What is the value you have in DSPPGM for
Program state  . . . . . . . . . . . . . . . . :   *USER or *SYSTEM?
If it
is *SYSTEM you'll need *SERVICE authority.

Rob Berendt