It's actually the SMFSTAMP8. format provided in the SAS language that converts the datetime format into a SAS datetime variable, which contains the number of seconds plus/minus Jan 1, 1960, the IBM epoch. (Unix and other use 1970).
There are 670 instances of variables INPUT with the SMFSTAMP8 informat in the MXG source library, and 1538 instances of variables INPUT with TODSTAMP8 informat. SMFSTAMP is limited to 2 decimal resolution (10 milliseconds) while most TODSTAMP8 fields have microsecond resolution. One of the beauties of SAS datetime variables is the ability to under specify the length of the datetime FORMAT (DATETIME21.2 for SMFSTAMP, DATETIME25.6 for TODSTAMP) so that FORMAT VARIABLE DATE9. ; can be used to summarize/report by DATE (06JAN2016) without creating a DATE variable, or FORMAT VARIABLE DATETIME12.; can be used to report/summarize by DATE and HOUR (06JAN2016:12) and FORMAT VARIABLE DATETIME13. can be used report/summarize by DATE/HOUR/and MINUTE (06JAN2016:12:30) without creating new variables. MERRILLY NEW YEAR, Barry Herbert W. “Barry” Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 ba...@mxg.com Fax: 214 350 3694 – Still works, received as email Tel: 214 351 1966 – Unreliable, please use email www.mxg.com HomePage: FAQ answers most questions ad...@mxg.com License Forms, Invoice, Payment, ftp information supp...@mxg.com Technical Issues MXG-L FREE ListServer http://www.mxg.com/mxg-l_listserver/ -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Neil Duffee Sent: Wednesday, January 06, 2016 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMFxTME field Caveat: with daily digesting, I'm at least a day behind the discussion... Actually, I believe that MXG is SMFxxDTE & SMFxxTME cognizant by virtue of using the underlying SAS 'inFormat's SMFDATETIME, SMFDATE, & SMFTIME. I do my SMF reporting using SAS directly and, using SMFDATETIME, get SAS Date/DateTime variables [1] that can have the (out) 'Format's you desire. [1] If I remember rightly, the SAS internal representations are #seconds or days from an arbitrary point ie. Jan 01, 1970 (or 1900?). That means, internally, the raw value can be negative for dates/times in previous (Gregorian) centuries, etc. --------> signature = 8 lines follows <-------- Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 "Schrodinger's backup: The condition of any backup is unknown until a restore is attempted." John McKown 2015 -----Original Message----- From: Charles Mills [mailto:cha...@mcn...org] Sent: January 5, 2016 19:46 Subject: Re: SMFxTME field Of course, if you have the good Doctor Merrill's most excellent MXG software then it will do all of this for you and more in but a trice! -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, January 05, 2016 4:30 PM Subject: Re: SMFxTME field The SMFxxTME and SMFxxDTE fields are in my experience consistent representations of *local* time and date on the LPAR represented by the SMFID. No worries about leap seconds (unless you need to get back to some more basic time than local). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
