Changes to Daylight Saving Time: MXG Software code is impervious to Daylight Savings Time; we give you the data that is in your RMF,SMF, etc. data, as you choose to create it.
If you choose to set your clocks back on an active system, you corrupt many datetime values (i.e, jobs end before they start, negative elapsed times, intervals end times before their begin time, etc.), and you will create multiple records with the same STARTIME in all RMF datasets, as well as CICINTRV, SMFINTRV, and any other interval datasets, but that's the result of your choice to set back clocks on an active system, and not of MXG's doing. If the records also contain an actual GMT Offset field, those pairs of same-STARTIME observations can be identified, but your hourly reports for the hour of time setback will have pseudo-duplicate data. Note that if your installation uses the TIMEBILD architecture (to tell MXG to change all datetime variables from SYSTEM's that are on different time zones to a common timezone), as long as you correctly update the mapping table in advance of the time change, MXG will correctly handle each system's time change, but, again, if you choose to set clocks back on an active system, all of the preceeding caveats apply. It is precisely when you have local time as a result of the GMT Offset that you are exposed to errors if you change the time (i.e., change the GMT Offset) backwards on an active system. If you have a GMT Offset of zero, and you keep all your clocks on GMT, there there is no change in your timestamps. This information was posted to our MXG-L ListServer in Dec, 2006. Herbert W. "Barry" Merrill, PhD ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
