Denis Robitaille wrote on 10/15/2007 04:25:06 PM:
I dont mind. In fact I apreciate a lot that you are taking the time to
help me. Here is the job log:
logcmd
Valeur d'audit modifiée pour le profil utilisateur TESTDR.
Valeur d'audit modifiée pour le profil utilisateur TESTDR.
/***************************************************/
/* You are running with ADOPTED access BE CAREFUL */
/***************************************************/
STRSRVJOB JOB(787861/@DROBI001/QPADEV000B)
strdbg SAR1125R
dspjoblog
The help text for STRSRVJOB says: The Start Service Job (STRSRVJOB)
command starts the remote service operation for a specified job
(other than the job issuing the command) so that other service
commands can be entered to service the specified job. Any dump,
debug, and trace commands can be run in that job until service
operation ends. Service operation continues until the End Service
Job (ENDSRVJOB) command is run.
The help text for STRDBG says: You must have either *CHANGE authority
to the program, or *USE authority to the program and *SERVICE special
authority.
So since your testing has shown that the user of LOGCMD must have *SERVICE
special authority we can conclude that the STRSRVJOB help text is correct
and that most of the work of the STRDBG command is being done in the job
being serviced. My guess is that the adopted authority will not be
available to STRDBG in this case because is doing the authority checking in
the serviced job.
If I am right, then a possible solution to this problem is to tell the
programmers to use LOGCMD to grant themselves *CHANGE authority to program
they wish to debug before they run STRDBG. Then when they are done with
the debug operation they should revoke their private *CHANGE authority to
that program. If that works perhaps you can automate this procedure (grant,
debug, revoke) in a new command that the programmers can only use from
within LOGCMD. Good luck.
Ed Fishel,
edfishel@xxxxxxxxxx
midrange.com
