RE: Identifying what job is calling QSH

First of all let me say that I love monitors that "assume" that when a
failure occurs that it's only because of a certain reason, like the
library was already in the library list. Not that there's any potential
that someone deleted the library. Because that obviously couldn't happen.
;-) But if that's not the case, IOW, if it can ignore that the libraries
no longer exist, then the application coded for it and you can ignore it.
Although I can't imagine a scenario that would be true. Well, maybe. Add
"custom commands" library to top of system library list. If that fails
then either the library is already in the library list or that it doesn't
exist and we can use the 'regular' system commands. I'm not saying I'm
perfect (I've got to fix a program I wrote that did an ALCOBJ with NO
monmsg).

Now which were you auditing for?
- Jobs that called QSH? or
- Jobs that had those libraries in their library list?

Date sent . . . . . . : 10/28/15 Time sent . . . . . . : 14:48:13
Message . . . . : addlible robdelme

Code . . . . . . . . : T - Audit trail entry
Type . . . . . . . . : ZR - Object read access
Object . . . . . . . :
Type . . . . . . . :
Date . . . . . . . . : 10/28/15
Time . . . . . . . . : 14:48:13.432880
...
Job . . . . . . . . : 756649/ROB/ROBS1
F15=Display only entry specific data
*...+....1....+....2....+....3..
'RROBDELME QSYS *LIB ¬

Yes, it does rather grind me that IBM fails to put the object in the
"Object" and "Type" and makes you look in the "Entry specific data".

Rob Berendt