Re: RDi debug & authority failures

On 23-Jun-2016 12:34 -0500, Justin Taylor wrote:

I don't get the AF entries when I do a STRSRVJOB. I typically use
RDi SEP's for debugging. I tried the "Debug As=>IBMi job" option in
RDi, and it also throws the AF entries.

AF entries (The last program is a SQL stored procedure of mine.):

Program Program | Object Library
name library | name name
|
QP0ZPCP2 QSYS | QWTPECTL QSYS
QP0ZPCP2 QSYS | QTEVINVR QSYS
QP0ZPCP2 QSYS | QLIRTVLL QSYS
QP0ZPCP2 QSYS | QLICHLLE QSYS
QP0ZPCP2 QSYS | QLICHLIB QSYS
QP0ZPCP2 QSYS | QLIRPLL QSYS
ISVAL00001 ODBC | QDMGETOV QSYS

That program name QP0ZPCP2 is the bottom of the stack of [most] HTTP server (QHTTPSVR) jobs, invoking procedures _CXX_PEP__Fv -> Qp0zNewProcess -> InvokeTargetPgm; these jobs apparently are not activated via the routing program QCMD as Type=BCH like those showing Function PGM-QZHBMAIN clearly being called from QCMD per the routing entry routing data. These other jobs are [¿presumably spawned?] Batch Immediate Type-BCI jobs; seems they are something for PASE for i under the "P2", I suppose operating much like how work is done for\from QP2TERM.? Unlike the prior list of programs, this one seems possibly to be just for some setup, possibly work to match the library list of the job to an associated\originating job or from a job description; the T-AF for the user routine\procedure is the only clearly anomalous event, even if somehow the others could be rationalized.

There doesn't seem to be much of interest in the joblog:
Attempt to use permanent system object QWTPECTL without authority.
Attempt to use permanent system object QTEVINVR without authority.
Attempt to use permanent system object QLIRTVLL without authority.
Attempt to use permanent system object QLICHLLE without authority.
Attempt to use permanent system object QLICHLIB without authority.
Attempt to use permanent system object QLIRPLL without authority.
Attempt to use permanent system object QDMGETOV without authority.

If I missed something, please let me know.

Still unsure of the /different user/; no info from the T-AF about the user or job name; what is the job [and current user] of the joblog shown above, also unknown -- what /user/ did the T-AF identify as lacking the authority.? That /joblog/ was taken as a copy\paste from an active and _displayed_ joblog, rather than the taken from an as-requested _spooled_ joblog; the latter gives some context, most notably, the from\to programs (and procedures if any\ILE) and instructions\statements.

No matter, I suppose. Without finding\offering a way to enable a recreate with some non-RDi debug, I personally would be hard-pressed to figure-out anything lacking some real good debug\trace info; i.e. I likely would need to do that myself, to figure out what is the real issue. I had alluded already, some past defects are similar, and the effects seen, being the unexpected T-AF per the msgMCH1001 [x0A01] errors [despite apparently being somewhat innocuous with regard to the expected outputs from debugging, per apparently being merely a nuisance vs a functional issue, and e.g. as one old APAR had stated for the circumvention, to just /ignore the errors/], seems a conspicuously improper outcome... So IMO, reporting the issue to your service provider, seems appropriate. They could login and review, whereas I can not -- at least nobody has ever been interested any time in the last decade when I have offered.

FWiW, AFaIK the SBREAK in a green-screen debug would be near identical to SEP debug from RDi; i.e. both SEP debug from a process separate from the job being debugged, assuming the job doing the SEP debug from 5250 is the same user as that of the server job for the RDi debug connection -- but that the server job for the client debug likely runs under a switched-user, might be a key attribute to mimic, and is something I have not tried -- and probably I will not spend the time to try. I do not have a similar environment in which to run with the highest degree of mimicry, nor anywhere I have full service\authority capabilities to dig, even if I could reproduce the issue.