Re: CHGSMTPA auditing

Sanjivji wrote:

I have Object auditing *change defined for CHGSMTPA

Someone changed firewall parm in it. How can I find as who did
it?

Even with auditing on CHGSMTPA I cannot see any journal entries
specific to it

Auditing *CHANGE for the *CMD object CHGSMTPA will not track usage [i.e. invocation] of the command, only if the *CMD object were changed. Only by using CHGOBJAUD QSYS/CHGSMTPA *CMD OBJAUD(*ALL) would logging of T-ZR entries logged for the use of the change SMTP attributes command. Thus why, probably, testing CHGSMTPA effected no logging. Of course be sure also that *OBJAUD is active in QAUDCTL, else no effects from CHGOBJAUD would be manifest in the auditing irrespective of chosen level of auditing for the object.

However, it may not be by that command interface from which changes were made. The iNav interface is more likely, and it probably does not use the *CMD object to effect the changes; rather an API or SPI is more likely. There is also the less likely case whereby a restore effected reverting to a prior level. And even less likely would be a[n improper\in error] conversion; e.g. on v6r1 the data in that member is converted to a new format, and in some odd instances either a conversion might be effected in error or a conversion might have an error in carrying the old value to its newer form.

The configuration data for SMTP is stored in a member CONFIG of the file QATMSMTP in QUSRSYS. DSPFD QUSRSYS/QATMSMTP will give information about restore or change activity to the member & data, and DSPOBJD QUSRSYS/QATMSMTP *FILE *FULL [and perhaps *SERVICE too] will record information more generally of the *FILE [not the member\data. However since the CHGSMTPA has already been used to change the data since the prior suspect change, the timestamp for when data had changed as displayed by the DSPFD member details, would no longer show the suspect change. But of course next time, collecting the OUTPUT(*PRINT) of the above command invocations before effecting any "correction" would leave a record of the timestamp for prior change activity.

If the file QATMSMTP is journaled [see the DSPFD & DSPOBJD] then DSPJRN of that journal to see what job at what time had changed the data; i.e. what\who\when the configuration was changed. If the file is not journaled, then either CHGOBJAUD QUSRSYS/QATMSMTP *FILE *ALL or STRJRNPF QUSRSYS/QATMSMTP to a journal to be reviewed after a suspect configuration change.

Regards, Chuck