On 14-Sep-2015 15:17 -0600, Jim Franz wrote:
Can I trust the user profile in a joblog of QZRCSRVS : did a F1 help
on the CPF9802 and F9 for Display message details - in this example
we know COKEK was not the user who made the request (she is the 1st
user when this particular QZRCSRVS job started) and am thinking the
Win side is connecting to an existing connection for another user.
As I recall, the message identifier xxxyyyy that logs the current
user [with text stating something like "job currently is servicing user
&1"] is /correct/ for the job; i.e. the most recent xxxyyyy, though I
seem to recall there is ever only one logged, else the joblog is wiped
clean as part of job-reuse or instead per the job having ended.
If the job is reused, then that message xxxyyyy names the new user
attached to the new\reused job. If the job is not reused, then that
message xxxyyyy would have logged the initial user that is currently or
was previously accessing the system, and any later messages logged will
refer to work initiated by that same named user; the job is continuing
to await more commands from the same user, or to be recycled\reused
according to timeouts and pre-start job configuration\settings. I
expect that a possible exception to what I described, would be if the
/command/ performed by the server job included a switch-user request
that was not reverted.?
Message ID . . . . : CPF9802 Severity . . . . . : 40
Message type . . . : Escape
Date sent . . . . : 09/14/15 Time sent . . . . : 13:53
Message . . . . : Not authorized to object GR_NONXYZ in QSYS.
Cause . . . : You do not have the correct authority for object
GR_NONXYZ in library QSYS type *USRPRF.
Recovery . . . : Contact your security officer or the object owner
to obtain the correct authority and try your request again.
Message ID . . . . : CPF9802 Severity
Date sent . . . . : 09/14/15 Time sent
Message type . . . : Escape
From . . . . . . . : COKEK CCSID .
From program . . . . . . . : QSYUP
From library . . . . . . : QSYS
Instruction . . . . . . : 3F1D
To program . . . . . . . . : K002C
To library . . . . . . . : KMD
To module . . . . . . . : K002C
To procedure . . . . . . : K002C
To statement . . . . . . : 2080
Time sent . . . . . . . . : 13:53:17.924614
The User named in the "From" may be the "current user" at the time
the F1=Help [or Display Job Log (DSPJOBLOG) command] is issued rather
than the current user that was active when the message was issued; i.e.
quite possibly the data comes from a pointer, from which the object name
gets materialized during the processing of the Display\Receive Message
request, rather than being retrieved from a stored-value that was
materialized when the message was originally issued.
However that is easily rendered moot, a non-issue, by reviewing
instead, the T-AF entry in the Audit Journal; i.e. look at auditing
results instead of looking at message(s) in the joblog.
I'm not entirely clear how the OS decides which connection is to
which QZRCSRVS job or if that is more of a client socket decision.
The C# developers gone for today to ask.
The QZRCSRVS server jobs are for the TCP Remote Command feature, and
the current-user should reflect the user profile that was utilized for
the Host Server authentication to the system [via, IIRC, the Signon
Server (*SIGNON server)].
Any suggestions on how to determine which QZRCSRVS job handles a
particular request would help. I've changed the jobd to log 4 00
*seclvl and logclpgm = *yes to see more detail .
IIRC there is an exit-point into which an exit-program can be
assigned. But as noted earlier, the simplest for the given scenario
likely is just [to establish auditing to include Authority Failure
(*AUTFAIL) events, and then] to review the T-AF in the log\journal-receiver.
Possibly easier still, is to use debug; add a breakpoint at the
failing statement\instruction, and then while the job is at the
breakpoint, review what is the value of "Current User Profile" for the
job [i.e. WRKJOB OPTION(*STSA)]. For example ADDBKP '/3F1D' PGM(QSYUP)
or establish a breakpoint at statement 2080 of the procedure K002C in
program K002C in library KMD; for the latter, add a SEP breakpoint to
avoid having to track-down the specific server-job to service [which is
probably the impetus for the "determine which QZRCSRVS job"].