For users looking for sample as discussed in community thread regarding creating audit trail of SSM table updates
difference is that my solution records it on the origin system.....
Dave, I added an MSFID column that I populate with this stmt:
Good point on xsys update Marcel. Original effort of putting this code together was to just illustrate the logic to interrogate the specific data used in the sql instruction. Didn't think about xsys updates. Various changes can be added to address this in addition to adding system column and recording xsys updates to each system from the focal system as you suggested. I recently modified this sample logic at a current site I'm at to address this issue by simply appending SYSTEM(sec.ausqsyna) to the SQL INSERT statement if the variable is not null (set to MSF system). With this logic the update to the history table would be in the table on the system the update was being performed. Could also add some info in the sql action variable date to include something like '***Xsys update from ' sec.ausqsyna ' if you would like to know the action was done on another system. If using OPS/MVS sysplex variables, you could make some simple changes to record the update info within sysplex variables . This would allow you to get SSM update history from any system in the sysplex which may be of use if some system in the plex is having issues IPLng and you want to see if any recent SSM configs were done on that system. Various ways to address this issue 'if' CA formalizes the sample in the future.
Unfortunately this sample does not take into account changing a remote table via MSF. There should be a column included indicating the target lpar where the table was modified...
Marcel van Ek