Re: Directory Entry ussage

On 09-Sep-2016 09:58 -0500, Steinmetz, Paul wrote:

So I would have to turn on auditing for SNDDST, SNDNETSPLF, and any
other command(s) that require a directory entry. Audit for a few
weeks, months, then review the QAUDITCD entries selecting those
commands. From that I could see which users are calling SNDDST,
SNDNETSPLF, etc. Not 100%, but a good start. Am I on the right
track?

With that approach, be sure to review all commands under each of these command groups [grouping menus, or perhaps try to compose a query of command names] for their potential usage of the Directory Entry support:

GO CMDDIRE
GO CMDNETF
GO CMDNET /* other NET that are not NETF; JOB,SPLF,MSG */
GO CMDDSTQ /* not sure, doubtful, any here use the feature */
GO CMDDST
GO CMDFLR
GO CMDDLO
GO CMDDOC
GO CMDNFS /* per another ref; likely just note STR??? */
GO CMDDSK /* likely only the RTVDSKINF */
/* RCLSTG and RCLOBJOWN might require enrollment too? */

Also, if the QAO* [QAOK* and QAOS*] files in QUSRSYS are [changed to be] journaled including *OPNCLO entries, those should identify any job starting the [I believe pseudo effect of, though perhaps an actual] activation group to open those /directory entry/ files in a job; only the effect of the first command that needs the files might appear for any one job, however, pending the [forced] close -- that is, they try to scope the open to a job to avoid open\close activity for repeated functions throughout a job that might again need to access directory entry information. Note: I believe the standard journal for these files is the *JOB object QAOSDIAJRN in QUSRSYS.

Or if the program(s) that open those files are audited, or instead [if there is] a program that notices that the open persists and thus just use the files, then that approach might be more definitive [at least for finding user jobs that use the feature even if they are not aware how, nor the usage conspicuous from review of that journal entry]. But if the research correctly identified the system programs doing that work. then that should be helpful.? I expect the Open Database File exit feature excludes /system/ open of files, so that probably would not be an alternative.

Effectively, all _usages_ of a DIRE should go through the arbiter [the owner of the feature; component OK?] to access the Directory Entry information. So if any code asks for any data or asks of any feature that depends on that data, then they should be asking of that [set of] program(s). Thus why auditing the specific system program(s) should at least catch every use.