Re: RDi debug & authority failures

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

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.

What is the IBM i OS release and cumulative level? The actual spooled joblog from the job identified by the T-AF would provide the most specific symptoms and some pertinent context; i.e. symptoms more capable of being searched than only knowing of the T-AF, such as specifically the program to which [i.e. T/pgm_name] the msgMCH1001 was signaled from the LIC Authority Exception notifier [i.e. F/#auexcpt]. What kind of program [ILE or OPM; for the latter, presumably then, compiled with OPMSRC(*YES)] and what kind of debug activity is requested [SEP, STEP INTO, set break-point] when the error occurs? Does /different user/ mean different than the user servicing the job, or that the current user of the serviced job is different than the job-user that was originally used to start the job, or something else? Perhaps just define all of the users of the scenario; the user of the qualified JOB() name being debugged, the current-user of the JOB() being debugged, the user that initiated and is performing the debug, the user identified in the T-AF as having encountered the msg MCH1001 [aka x0A01].

FWiW: similar effects were documented in some very ancient APARs: APAR SE26773 and APAR SE34653