Re: RDi debug & authority failures

On 03-Jun-2016 13:28 -0500, Justin Taylor wrote:

On 03-Jun-2016 08:24 -0500, Justin Taylor wrote:

On 03-Jun-2016 07:52 -0500, Justin Taylor wrote:

I'm debugging an RPGLE webservice that uses CGIDEV2. It's
generating a lot of authority failures (AF) against IBM objects
(QSYS/Q* stuff). I can't change the user profile it's running
under. Is there any good way to eliminate those AF entries?

The AF entries only occur in debug. They actually happen any time
I debug a job running as a different user. The app and the debug
both work fine with no apparent problem.

Recap:
I'm debugging RPG code using RDi. If the job is running under a
different user, I get a large number of authority failures generated
in the security log. Is there any good way to eliminate those AF
entries?

Here's the list of objects:

Object Library
name name
QDBCHKLA QSYS
QDBGETKY QSYS
QDMCOPEN QSYS
QDMCRODP QSYS
QDMGETOV QSYS
QDMROUTE QSYS
QTEVINVR QSYS
QTEVSIRF QSYS
QTQGETCC QSYS
QWCSRTLR QSYS
QWTPECTL QSYS
QWVAGSRV QSYS

Cross-post WDSc & Midrange lists.

Eliminating the T-AF entries is predicated on discovering their origin. Seems unlikely that they are entirely appropriate; from the list of programs [despite collation by name rather than timestamp], their appearance seemingly is a side effect of a code path performing a keyed database file open and keyed read, and that work is a side effect of the debug[ger] activity performed as work in the job under a current-user. I'm just not sure how the events might come about, while not also causing something to conspicuously fail; seems possible that some authority was obtained and stored using the job-user having some level of authority and then references by the switched-to\current user with a different level of authority.

The T-AF details reveal what qualified program name encountered the Authority Failure event [exception x0A01], as well as the qualified job name. For each of those program objects named\listed above, is the named program the same? Presumably, the job from which the AF events originate, is the CGIDEV2 job running with the /different user/; or perhaps instead a server job that implements the debug server from the client? Other information from the T-AF such as the /violation type/ and the /user profile name/ may be pertinent; the user identified by the T-AF is likely the /different user/, though notably, /different/ _from what_ is unclear, per left unstated. The program instruction number likely would be of interest only if not IBM code, or to confirm where within a trace, the event occurs. Can a spooled trace of the job (TRCJOB) that originates the T-AF entries] be gathered\presented, to better show what processing gives rise to those aut failures? And can the spooled joblog for that job be gathered\presented?

Is the issue specific to debug from RDi, or does the same issue occur from green-screen debug when using Start Service Job (STRSRVJOB) to debug the job running with the /different user/; or sbreak if that is the means via RDi?