Time zone adjustment on IBM Security Guardium and z/OS S-TAP

Answer

It's important for the collector and db server to operate (or at least mimic operating) in the same timezone to ensure that operations work as expected on the appliance, including, for example, export operations from the collectors to the aggregators, which relies on session timestamp information to determine which Guardium audit data to export to the aggregator. If the timezones are different, you run the risk of actually missing audit data in the aggregated reporting especially if the two time zones span the midnight boundary. There are many other Guardium operations that rely on timestamp data as well.

For this reason, V10 DB2 S_TAP and snif patch v10p4009 added code to convert the z STAP information to the collector timezone before logging it. (Previously, the S-TAP only sent a timezone string of the database local time.) For most organizations, this is not an issue as it is best practice to have collector and database server in the same timezone. For those who have their z/OS STAPs in a different timezone (or set those servers to GMT for example so it acts as if it's in a different timezone), you may see a timestamp change from what you had before.

After many years of having the z/OS STAP traffic be treated differently to other platforms. Patch V10p4009 was finally issued to bring the z/OS STAP platforms in line with how traffic is processed from other platforms such as Linux, Unix and Windows.