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
As an Amazon Associate we earn from qualifying purchases.
	
 
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.