Re: Identifying what job is calling QSH

On 28-Oct-2015 13:14 -0500, Steinmetz, Paul wrote:

CRPence on Wednesday, October 28, 2015 1:27 PM wrote:

On 28-Oct-2015 11:15 -0500, Steinmetz, Paul wrote:

<<SNIP>>

From the QAUDJRNJS, I have one job running daily at 8:00 am,
that calls QSH, (QZSHSH, QPOZSPWP) still has the 3rd party app
libraries in their library list.

How can I find what job is calling QSH that still contains these
3rd party app libraries?

I expect [from memory alone; i.e. not as verified by an actual
test] that by locating the T-JS [Audit:Job Data] entry for one of
those jobs, that in the Standard Heading Fields For Audit Journal
Entries will be revealed the qualified job name of the job that
performed the QSH request.
[http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/rzarl/rzarlf01.htm]
_Standard heading fields for audit journal entries_ ...
"This table lists all possible values for the fields that are
common to all entry types when OUTFILFMT(*TYPE5) is specified on
the DSPJRN command.
..."

The T-JS could be located by the start time of the job, and\or by
looking for the [and additionally to confirm the correct] entry
having the Job Name='QZSHSH' [and the corresponding Job User Name
and Job Number; probably also with Entry Type='S' and Job
Subtype=D].
[http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/rzarl/rzarlf28.htm]
_JS (Job Change) journal entries_
"This table provides the format of the JS (Job Change) journal
entries.
..."

And if not revealed with that job [the Job Name='QZSHSH'], then the
other job [the Job Name='QPOZSPWP']; i.e. again, the job to which
the T-JS is associated, for at least one of those Qxxx jobs,
presumably will be the job that had issued the QSH request.

The 2 JS entries contain for job name, QZSHSH and QP0ZSPWP, does not
show the name of the job calling QSH.

Entry Sequence Code Time Job User Job Program
len number -Typ name name
3726 0218985752 T-JS 080002810256 QZSHSH CPACOPER 406267 QWTPIIPP
3726 0218985756 T-JS 080002830352 QP0ZSPWP CPACOPER 406268 QWTPIIPP

Huh. I was thinking the T-JS was associated with the job that had initiated a job rather than the job that was initiated. So, if the above show the qualified job names appearing as "The name of the job that caused the entry to be generated" from the Standard Heading Fields of the T-JS entry, then what about the qualified Job Name information that is recorded in the Entry Data as the individual "part[s] of the qualified job name being operated on"? If the the other qualified job name information records the identical information, then that would seem rather daft, that the T-JS would not reveal both the job being started *and* the job that started the job for the entry recording the 'S'tart of a job?

By checking QHST I did find a few jobs that started at 8:00, I
checked those job logs, found this.

CPF1124 Info 00 10/28/15 08:00:00.093493
QWTPIIPP QSYS 04C0 *EXT
Message . . . . : Job 406251/CPACOPER/BRCCHKFREE started on
10/28/15 at 08:00:00 in subsystem BATCH_CM in GPL. Job entered system
on 10/28/15 at 08:00:00.

CPC2196 Comp 00 10/28/15 08:00:02.563700
QLICUSRL QSYS 0114
VPVPGM01 BRCPGMSN *STMT
To module . . . . . . . . . : VPVPGM01
To procedure . . . . . . . : VPVPGM01
Statement . . . . . . . . . : 1851
Message . . . . : Library G1C1PGMS added to library list.
CPC2196 Comp 00 10/28/15 08:00:02.563975
QLICUSRL QSYS 0114
VPVPGM01 BRCPGMSN *STMT
To module . . . . . . . . . : VPVPGM01
To procedure . . . . . . . : VPVPGM01
Statement . . . . . . . . . : 1856
Message . . . . : Library G1C1FILES added to library list.

Within VPVGP01 I did find this.

0315.00 C MONITOR
0316.00 C CALLP Cmd('ADDLIBLE LIB(G1C1PGMS)':200)
0317.00 C ON-ERROR
0318.00 C ENDMON
0319.00
0320.00 C MONITOR
0321.00 C CALLP Cmd('ADDLIBLE LIB(G1C1FILES)':200)
0322.00 C ON-ERROR
0323.00 C ENDMON

So the question was able to be answered, just not by direct review of the QAUDJRN data itself; instead by review of some QAUDJRN data that assisted in [led to] locating a joblog from which the context provided in the messaging [from-program info] allowed redirection to the source of that program which revealed the command-request [to be the ADDLIBLE command].

My question is why did I not find QAUDJRN entries for job BRCCHKFREE
showing the ADDLIBLE?
<<SNIP>>

I suppose why that is, depends on _how_ that search was conducted.

From the OP [although I had snipped that from what I quoted, so I have re-inserted here\below] the following was noted as the means used to search:

I used QAUDJRN to find all uses where any of the libraries may
have been used, added (ADDLIBLE, EDTLIBL)

SELECT * FROM qgpl/QAUDITjs WHERE locate ('G1',JSLIBL ) <> 0

Of course I am unsure what exactly that search accomplishes, nor what was the origin of the data in the file QAUDITjs. Yet one might surmise [from the file name] that the data in the file was T-JS entries, and also to presume that that T-JS data was inclusive of the time-period when the jobs were started.

But even assuming as much, given the T-JS reflects the initiation of and the change to jobs, I am not sure there would be a T-JS logged every time a LIBL entry changed... that would seem a tad excessive.?

Recalling a past discussion in which I had expressed the same concern, and what I recall as a similarly formulated query, I found the OP from an old topic thread Subject: "Scaning field JSLIBL from QAUDJRN outfile QASYJSJ5" that describes use of a similar file and eventually refers to a like-query:
[http://archive.midrange.com/midrange-l/201407/threads.html#00384]

I seemed equally dubious in that topic, in questioning that "every single library-list modification [would be] causing a T-JS" entry to be logged:
[http://archive.midrange.com/midrange-l/201407/msg00503.html]

I suggested back then, as well, that "I infer that the empty result set of the query suggests only that the named library has never been part of the *LIBL within a job that has been *started* [or transitioned across a captured job status; e.g. CHG, HLD, RLS, DSC, etc.] on the system over that period.":
[http://archive.midrange.com/midrange-l/201407/msg00419.html]

And the conclusion in that thread was that indeed, the T-JS entry can *not* be utilized to locate [e.g. using the LOCATE scalar] the effects of an ADDLIBLE quite likely because "that level of auditing would be too aggressive\onerous to have been allowed so generally" every time a modification occurred to the Library List of a job, and that instead the T-CD [I accidentally called them T-CS in that discussion] would probably best be used instead:
[http://archive.midrange.com/midrange-l/201407/msg00614.html]

And additionally, re the reference to EDTLIBL in the OP, that command was explicitly noted to be even more problematic for searching than would be ADDLIBLE, because the modifications via the interactive "Edit" panel are not visible in the command-string, thus the T-CD would be unhelpful without additional work... and a tangent of the thread covered ways to encompass the effects of that feature too [I presume as output to the audit journal, but I do not recall, and I have stopped reviewing the old topic thread].

I think likely then, that pretty much sums up why the data was not found when searching T-JS data [instead of searching T-CD] data. And which apparently was already discovered to reveal the desired info, that the ADDLIBLE was used by some job, as noted in a followup to this thread:
[http://archive.midrange.com/midrange-l/201510/msg00861.html]

Of course, that still leaves unresolved, the question about how to determine the job that performed the QSHELL work that had initiated the job QZSHSH and QPOZSPWP.