Re: Age of datasets in hours, not days?
In cae1xxdegehhtqobec5d5aa9ge-jc8cpfrpjqgdb1e-8qmbz...@mail.gmail.com, on 06/07/2013 at 02:58 PM, John Gilmore jwgli...@gmail.com said: I suspect that you two will continue in your naif views, but let me try one more time, taking first Mr Gilmartin and then Dr Merrill. It is quaint for one who engages in spelling flames to confuse a noun with an adjective; it is even more quaint to accuse Dr. Merrill of being a naif or of having naïve views in an area where he has so much experience. Leap seconds correct for this precession, keeping UTC seasonally aligned, Not even close; leap seconds restore alignment of the clock with the Earth's rotation; it is leap days that restore seasonal alignment. Neither has anything to do with precession. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
I am a little weary of correcting misapprehensions. Who asked you to? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Did you notice the z/OS 1.13 enhancement in SMS, where the creation time is also stored in the new F9 DSCB? Currently only for datasets that create a F9 DSCB. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, June 06, 2013 18:38 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? Thanks, all. Yeah, I know about putting a code into the name. There are of course complications to doing that. I really want something like LISTCAT so SMF is not the answer. I will pursue other approaches. (Yes, I should have said non-VSAM.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 06, 2013 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? Of course, if you want date/time stamps the other option (not my favorite) is to bury it in the DSN if you need real-time like information. If you can wait for the SMF data, you can pull from there. HLQ.Ttime.Ddate.etc Or create a meta database in your app that when you create a dataset, you log it. But NON Vsam does not have a lot of bells and whistles without a lot of exits and work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On 6/6/2013 11:39 PM, Vernooij, CP - SPLXM wrote: Did you notice the z/OS 1.13 enhancement in SMS, where the creation time is also stored in the new F9 DSCB? Currently only for datasets that create a F9 DSCB. DS9JOBNAME DS CL8 Job name used to create the * data set described by its * format 8 DSCB @V2A DS9STEPNAME DS CL8 Step name used to create the * data set described by its * format 8 DSCB @V2A DS9TIME DS XL6 Number of microseconds since * midnight, local time, that the data * set described by its format 8 DSCB * was created. See creation date * field, DS1CREDT, for the date @V2A -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote: ... the creation time is also stored in the new F9 DSCB ... DS9TIME DS XL6 Number of microseconds since * midnight, local time, that the data * set described by its format 8 DSCB * was created. See creation date * field, DS1CREDT, for the date @V2A Local time in microseconds!? Get real! Haven't the designers come to appreciate the folly of storing timestamps in local time with an annual Daylight Saving Time ambiguity during 3,600,000,000 microseconds? That's a lot of microseconds. Is it truly in hexadecimal display as the type 'X' would seem to imply? Can't be. 6 isn't enough: gil@MVS:128$ rexx numeric digits 20; X = d2x( 24*60*60*100 ); say length( X ) X 10 141DD76000 Would FL6 make more sense notionally? (But is FL6 even legal?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
I am not sure I understand Paul Gilmartin's last post. XL6 specifies a target, assembled length of six bytes. There are 6 x 8 = 48 bits available in these 6 bytes. A 24-hour day contains 60 x 60 x 24 x 1,000,000 = 29,664,400,000,000 µsec 2^48 - 1 = 281,474,976,710,655 These six bytes are thus entirely adequate to contain any unsigned elapsed-µsec value in a 24-hour day. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
John Gilmore wrote: These six bytes are thus entirely adequate to contain any unsigned elapsed- µ - sec value in a 24-hour day. Agreed. Only if all users of that 6 bytes are still using it as *un-signed* value. There must be a reason, why such precision is needed? Any one willing to share what that reason is? Only precise answers on a punch card, please... ;-D Groete / Greetings Elardus Engelbrecht John, am I correct, you're refering to 'lower-case letter mu (μ)' ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
I'd say first: there must be a reason to store the creation time. What was the reason? So if IBM decided to store the creation time rounded only to minutes or seconds, people would complain that it should be more accurate. If so, it is a wise decision to store it accurate enough for now and the near future to avoid duplicate creation times, remember the job readertime 'accuracy'? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Friday, June 07, 2013 14:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? John Gilmore wrote: These six bytes are thus entirely adequate to contain any unsigned elapsed- µ - sec value in a 24-hour day. Agreed. Only if all users of that 6 bytes are still using it as *un-signed* value. There must be a reason, why such precision is needed? Any one willing to share what that reason is? Only precise answers on a punch card, please... ;-D Groete / Greetings Elardus Engelbrecht John, am I correct, you're refering to 'lower-case letter mu (μ)' ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
IMO, if IBM were to store the creation date time, then the only logical value to store is the STCKE value taken somewhere within the allocation process. It is 16 bytes in length and cannot be made any more accurate because the hardware doesn't support a greater accuracy. It is not human readable, but SO WHAT? It is easy to convert using HLASM and the STCKCONV macro. I wish that the LE people had an STCKE value to Lilian date/time conversion routine. But, again, that would be easy to write in HLASM. On Fri, Jun 7, 2013 at 7:20 AM, Vernooij, CP - SPLXM kees.verno...@klm.comwrote: I'd say first: there must be a reason to store the creation time. What was the reason? So if IBM decided to store the creation time rounded only to minutes or seconds, people would complain that it should be more accurate. If so, it is a wise decision to store it accurate enough for now and the near future to avoid duplicate creation times, remember the job readertime 'accuracy'? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Friday, June 07, 2013 14:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? John Gilmore wrote: These six bytes are thus entirely adequate to contain any unsigned elapsed- µ - sec value in a 24-hour day. Agreed. Only if all users of that 6 bytes are still using it as *un-signed* value. There must be a reason, why such precision is needed? Any one willing to share what that reason is? Only precise answers on a punch card, please... ;-D Groete / Greetings Elardus Engelbrecht John, am I correct, you're refering to 'lower-case letter mu (μ)' ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Pedantry follows: John McKown wrote of an STCKE value it is 16 bytes in length . . . , and this is literally true, but the rightmost two-byte programmable-field value is not part of the TOD value. The leftmost 14-byte/112-bit substring is the TOD value. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On Fri, 7 Jun 2013 07:29:09 -0500, John McKown wrote: IMO, if IBM were to store the creation date time, then the only logical value to store is the STCKE value taken somewhere within the allocation process. It is 16 bytes in length and cannot be made any more accurate because the hardware doesn't support a greater accuracy. It is not human readable, but SO WHAT? It is easy to convert using HLASM and the STCKCONV macro. I wish that the LE people had an STCKE value to Lilian date/time conversion routine. But, again, that would be easy to write in HLASM. Does STCK still guarantee unique readings, even subsequent to the advent of STCKE? 24 hours of binary mircoseconds isn't very human readable either. And still using local time leaves wide open the hour of uncertainty every fall. It makes no sense to provide microsecond resolution while tolerating that hour of uncertainty. Were the designers even thinking? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
The sequence of both STCK and STCKE values is a unique, monotone ascending ones, so that even two successive STCK[E] instructions executed on the same CP yield such values. The programmable field serves a different purpose. It identifies which TOD clock in a multiclock SYSPLEX provided a particular STCKE value. My difficulties with Paul Gilmartin's post continues. Appropriate correspondences with civil date-time values are sometimes very important indeed, but they are not just irrelevant but a gratuitous complication when one is dealing in elapsed-time intervals. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote: DS9TIME DS XL6 Number of microseconds since * midnight, local time, ... Did I fail to read this correctly previously? Now that I look more carefully, it seems to be saying that the field stores a counter that is reset to 0 each midnight, local time, and counts uniformly until the next midnight. So on most days, it will reset after 24 hours worth of microseconds. On the day of the Fall Daylight Saving Time boundary, it will reset only after 25 hours' worth of microseconds; on the day of the Spring Daylight Saving Time boundary, it will reset after only 23 hours' worth of microseconds. No ambiguity, but tricky to convert to local time. And the best way for allocation to compute the needed value is to save the (E)TOD value each midnight and subtract from the (E)TOD value at the time of allocation. Are there locales where the Daylight Saving Time boundary occurs at midnight, or spans midnight so there might be two midnights, an hour apart? Or none, in the Spring? Leap seconds? If one is concerned with microsecond precision, one needs to be concerned with how leap seconds are treated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Nicely avoiding DST problems and leaving them to the customer. The leapsecond is added after 23:59:59, so before midnight. No confusion there. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 07, 2013 16:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote: DS9TIME DS XL6 Number of microseconds since * midnight, local time, ... Did I fail to read this correctly previously? Now that I look more carefully, it seems to be saying that the field stores a counter that is reset to 0 each midnight, local time, and counts uniformly until the next midnight. So on most days, it will reset after 24 hours worth of microseconds. On the day of the Fall Daylight Saving Time boundary, it will reset only after 25 hours' worth of microseconds; on the day of the Spring Daylight Saving Time boundary, it will reset after only 23 hours' worth of microseconds. No ambiguity, but tricky to convert to local time. And the best way for allocation to compute the needed value is to save the (E)TOD value each midnight and subtract from the (E)TOD value at the time of allocation. Are there locales where the Daylight Saving Time boundary occurs at midnight, or spans midnight so there might be two midnights, an hour apart? Or none, in the Spring? Leap seconds? If one is concerned with microsecond precision, one needs to be concerned with how leap seconds are treated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On 2013-06-07, at 08:09, Vernooij, CP - SPLXM wrote: Nicely avoiding DST problems and leaving them to the customer. Indeed. The leapsecond is added after 23:59:59, so before midnight. No confusion there. Is it well specified whether the leap second is added after 23:59:59 UTC or after 23:59:59 local time if the two happen to differ? I've long wondered at which point I should reset my watch which I keep on local time. If it had sub-second accuracy. Your KLM return address suggests that you might not have to deal with any difference between UTC and local time. Unless you're a pilot. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
https://en.wikipedia.org/wiki/Leap_second Time of day adjustments occur on the last second of any day of any month, but so far have only occurred on Dec 31 or Jun 30. You could skip 23:59:59 or add 23:59:60 UTC, simultaneously around the world. On Fri, Jun 7, 2013 at 9:32 AM, Paul Gilmartin paulgboul...@aim.com wrote: On 2013-06-07, at 08:09, Vernooij, CP - SPLXM wrote: Nicely avoiding DST problems and leaving them to the customer. Indeed. The leapsecond is added after 23:59:59, so before midnight. No confusion there. Is it well specified whether the leap second is added after 23:59:59 UTC or after 23:59:59 local time if the two happen to differ? I've long wondered at which point I should reset my watch which I keep on local time. If it had sub-second accuracy. Your KLM return address suggests that you might not have to deal with any difference between UTC and local time. Unless you're a pilot. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Leap seconds increment a seconds counter (or a surrogate for one). The appropriate conversion routine then produces a Gregorian date or the like from this value. Never, never try to increment or decrement a calendar date programmatically: that way madness lies. Conceptial confusion lies there too: there is no xx.xx.60 UTC John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On 6/7/2013 5:29 AM, John McKown wrote: IMO, if IBM were to store the creation date time, then the only logical value to store is the STCKE value taken somewhere within the allocation process. It is 16 bytes in length and cannot be made any more accurate because the hardware doesn't support a greater accuracy. It is not human readable, but SO WHAT? It is easy to convert using HLASM and the STCKCONV macro. I wish that the LE people had an STCKE value to Lilian date/time conversion routine. But, again, that would be easy to write in HLASM. As a software developer, I have had multiple occasions to process event times stored as all or part of a TOD value. For obvious reasons, end users prefer everything displayed to them in local time. Therefore, accurate reporting of these events in human-readable form requires knowledge of the locale's time zone policy going back many years (for (E)JES, we go back 10 years). For this reason, I have come to very much appreciate event times stored as local time. For example, ISPF stores member create/update time as a local time value. No conversion necessary. Of course, for 100% coverage of all possible usage scenarios, time stamps should contain both UTC and local time. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of John Gilmore :: Sent: Friday, June 07, 2013 4:52 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Age of datasets in hours, not days? :: :: I am not sure I understand Paul Gilmartin's last post. :: :: XL6 specifies a target, assembled length of six bytes. There are 6 x :: 8 = 48 bits available in these 6 bytes. :: :: A 24-hour day contains 60 x 60 x 24 x 1,000,000 = 29,664,400,000,000 :: µsec Your calculator broken or are using a base other than 10? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On 6/7/2013 9:25 AM, retired mainframer wrote: :: A 24-hour day contains 60 x 60 x 24 x 1,000,000 = 29,664,400,000,000 :: µsec Your calculator broken or are using a base other than 10? Should be 86,400,000,000 µsec. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Of course, for 100% coverage of all possible usage scenarios, time stamps should contain both UTC and local time One timestamp and the GMT offset takes less space and is IMO all that is needed. Barry Merrill Herbert W. “Barry” Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com - FAQ has Most Answers ad...@mxg.com – invoices/PO/Payment supp...@mxg.com– technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 – prefer email, still works -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Friday, June 07, 2013 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? On 6/7/2013 5:29 AM, John McKown wrote: IMO, if IBM were to store the creation date time, then the only logical value to store is the STCKE value taken somewhere within the allocation process. It is 16 bytes in length and cannot be made any more accurate because the hardware doesn't support a greater accuracy. It is not human readable, but SO WHAT? It is easy to convert using HLASM and the STCKCONV macro. I wish that the LE people had an STCKE value to Lilian date/time conversion routine. But, again, that would be easy to write in HLASM. As a software developer, I have had multiple occasions to process event times stored as all or part of a TOD value. For obvious reasons, end users prefer everything displayed to them in local time. Therefore, accurate reporting of these events in human-readable form requires knowledge of the locale's time zone policy going back many years (for (E)JES, we go back 10 years). For this reason, I have come to very much appreciate event times stored as local time. For example, ISPF stores member create/update time as a local time value. No conversion necessary. Of course, for 100% coverage of all possible usage scenarios, time stamps should contain both UTC and local time. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- 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
Re: Age of datasets in hours, not days?
I am or was then, I hope temporarily, the thing broken. The correct value is: 86,400,000,000 µsec Fortunately/serendipitously my argument is unimpaired. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On Fri, 7 Jun 2013 12:12:01 -0400, John Gilmore wrote: Never, never try to increment or decrement a calendar date programmatically: that way madness lies. Conceptial confusion lies there too: there is no xx.xx.60 UTC From: http://datacenter.iers.org/somos/rest/document/body/tx13iers.8q2/bulletinc-043.txt A positive leap second will be introduced at the end of June 2012. The sequence of dates of the UTC second markers will be: 2012 June 30, 23h 59m 59s 2012 June 30, 23h 59m 60s 2012 July 1, 0h 0m 0s From: ftp://tycho.usno.navy.mil/pub/gps/leapsecnanu.txt NOTICE ADVISORY TO NAVSTAR USERS (NANU) 2012034 SUBJ: LEAP SECOND 1. CONDITION: THE INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) HAS ANNOUNCED THE INTRODUCTION OF A LEAP SECOND TO OCCUR AT THE END OF JUN 2012 2. COORDINATED UNIVERSAL TIME (UTC) WILL SEQUENCE AS FOLLOWS: 30 JUN 2012 23 HOURS 59 MINUTES 59 SECONDS 30 JUN 2012 23 HOURS 59 MINUTES 60 SECONDS 01 JUL 2012 00 HOURS 00 MINUTES 00 SECONDS From: http://www.nist.gov/pml/div688/leapseconds.cfm When do leap seconds occur? Leap seconds have always occurred at the end of December or the end of June, on the last second of the UTC day. The designation of the sequence of seconds is: 23h 59m 59s 23h 59m 60s 00h 00m 00s I consider these highly authoriitative sources. What's your source of information? I suspect it comes from the same culture that decrees the prefix Mega stands for 1,048,576. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Splain why a database is needed if the GMT offset value is the correct delta, that is, of course, reset when times are changed between GMT and offset value. Or explain why the second datetime stamp, which would have the same delta as the offset in effect, adds anything? Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, June 07, 2013 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? Barry Merrill wrote: | One timestamp and the GMT offset takes less space and is IMO all that | is needed. but Edward Jaffe is correct; unless that offset is supplemented by a database of historical and current information about locale-specific daylight-saving/summer/official/... time in-effect intervals that would be hard to construct and difficult to maintain. There are indeed several such databases in existence; and, while they do have some limited usefulness for manual consultation, their coverage is too limited and their accuracy is too low to make them useful for reference from a conversion routine. John Gilmore, Ashland, MA 01721 - USA -- 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
Re: Age of datasets in hours, not days?
In 51b2083c.3060...@phoenixsoftware.com, on 06/07/2013 at 09:20 AM, Ed Jaffe edja...@phoenixsoftware.com said: Of course, for 100% coverage of all possible usage scenarios, time stamps should contain both UTC and local time. I'd prefer UTC and local offset. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On 6/7/2013 9:34 AM, Barry Merrill wrote: One timestamp and the GMT offset takes less space and is IMO all that is needed. That would suffice. Of course, one must remember to save the offset, then issue STCK[E], and then compare the saved offset against the current offset. If any change detected, loop back and start over... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
It may be that Dr Merrill and I have different objectives. My interest is only incidentally in this instant's STCKE value. It is in the use of such values as date-time values in both the post-1900 past and the not too remote future. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On Fri, 7 Jun 2013 14:58:01 -0400, John Gilmore wrote: Precession very gradually brings UTC (and other lunisolar calendars too) out of alignment with the seasons on earth. Leap seconds correct for this precession, keeping UTC seasonally aligned, or nearly so. That's the purpose of leap years. Leap seconds do not have anything to do with seasons, but with variations in the mean solar day. As I understand it, the problem that leap seconds address is that the speed of rotation of the earth is not constant. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
The rotation is not constant, and is too slow. It takes (a very little) more than 24 hours for the earth to make one rotation. What have I started!?! All I wanted to know was whether LISTCAT or the like supported dataset age granularity finer than one day! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Friday, June 07, 2013 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? On Fri, 7 Jun 2013 14:58:01 -0400, John Gilmore wrote: Precession very gradually brings UTC (and other lunisolar calendars too) out of alignment with the seasons on earth. Leap seconds correct for this precession, keeping UTC seasonally aligned, or nearly so. That's the purpose of leap years. Leap seconds do not have anything to do with seasons, but with variations in the mean solar day. As I understand it, the problem that leap seconds address is that the speed of rotation of the earth is not constant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On Fri, 7 Jun 2013 15:28:21 -0700, Charles Mills wrote: The rotation is not constant, and is too slow. It takes (a very little) more than 24 hours for the earth to make one rotation. What have I started!?! All I wanted to know was whether LISTCAT or the like supported dataset age granularity finer than one day! Indeed. And you got only a partial answer. It's in the DS9TIME field of the F9 DSCB, but no advice on interfaces to it. I suppose there's always EXCP. Looking for more information, I found: http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.adru000%2Fow19618.htm 2. For a preallocated target that has F8/F9 DSCBs, the F9 DSCB field DS9CREAT is set ON, and is being scratched and reallocated, these patch byte settings will not be honored. These types of data sets have a field in the F9 DSCB which corresponds to the number of milliseconds past midnight in which the data set was created (DS9TIME). In order for the DS9TIME to be usable, the creation date and the time past midnight of the preallocated target will be preserved as its value prior to scratching. Microseconds? Milliseconds? Who cares? They're both too small to be much concerned with. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Microseconds? Milliseconds? Who cares? They're both too small to be much concerned with. I'd settle for AM/PM at this point. It would be an improvement in granularity on local calendar days. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, June 07, 2013 4:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? On Fri, 7 Jun 2013 15:28:21 -0700, Charles Mills wrote: The rotation is not constant, and is too slow. It takes (a very little) more than 24 hours for the earth to make one rotation. What have I started!?! All I wanted to know was whether LISTCAT or the like supported dataset age granularity finer than one day! Indeed. And you got only a partial answer. It's in the DS9TIME field of the F9 DSCB, but no advice on interfaces to it. I suppose there's always EXCP. Looking for more information, I found: http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.adru000%2Fow19618.htm 2. For a preallocated target that has F8/F9 DSCBs, the F9 DSCB field DS9CREAT is set ON, and is being scratched and reallocated, these patch byte settings will not be honored. These types of data sets have a field in the F9 DSCB which corresponds to the number of milliseconds past midnight in which the data set was created (DS9TIME). In order for the DS9TIME to be usable, the creation date and the time past midnight of the preallocated target will be preserved as its value prior to scratching. Microseconds? Milliseconds? Who cares? They're both too small to be much concerned with. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Julian-calendar leap years are defined very simply as those that have serial numbers divisible by 4, those in the doubly infinite sequence . . . -12, -8, -4, 0, +4, +8, +12 . . . A four-year Julian-calendar cycle thus contains a mean of (3 x 365 + 1 x 366)/4 = 365.25 days. This is unsatisfactory for many terrestrial uses; precession accumulates gradually; and the seasons of the tropical year move slowly toward the beginning of the calendar year. (The Julian calendar nevertheless remains in use, in its traditional, medieval form by the Orthodox Churches and with Joseph Scaliger's 'new' epoch origin, the Gregorian date of which is -4713 November 24, by observational astronomers.) To reduce this precession the Gregorian calendar adds a second-order correction. Years are of two sorts: o centurial years, e.g., ..., -100, 0, 100,1500, 1600, 1700, 1800, 1900, 2000,... that have serial numbers divisible by 100, and o non-centurial years, all the others. Then 1) every fourth non-centurial year is a leap year and 2) every fourth centurial year is also a leap year, In other words, a non-centurial year is a leap year iff its serial number is divisible by 4; and a centurial year is a leap year iff its serial number is divisible by 400. In the upshot there are occasional intervals of seven successive non-leap years centered on a non-leap centurial year, e.g., 1897, 1898, 1899, 1900, 1901, 1902, 1903 2097, 2098, 2099, 2100, 2101, 2102, 2103, and the like. (2000 was of course a leap year.) .* A year in the 400-year Gregorian-calendar cycle thus contains a mean of (303 x 365 + 97 x 366)/400 = 365.2425 days. This is still very imperfect. It is better, yields less long-term precession than did/does the Julian calendar.. A mean tropical year, the time between successive vernal equinoxes, is shortening very slowly. Its current length is about 365.2421_9668 days. The year +3600, a centurial year having a serial number that is exactly divisible by 400, satisfies the definition of a leap year; but it will be a non-leap year by fiat in order to sop up some accumulated precession. Leap seconds deal with accumulating precession that is not dealt with effectively by the definition of the Gregorian calendar. There are many reasons for this precession, most of them classical and well understood. If you know German consult the relevant volumes of C F Gauß, Werke. If you know French, consult Laplace's Mécanique celeste. I am a little weary of correcting misapprehensions. John Gilmore, Ashland, MA 01721 - USA t. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Leap seconds deal with accumulating precession that is not dealt with effectively by the definition of the Gregorian calendar. I don't *think* so. I think they deal with the rotation of the earth on its axis taking more than 24 hours, as opposed to a rotation around the sun taking more than 365 days (the February 29 and associated leap year adjustments). A clock problem as opposed to a calendar problem if you will. A leap second is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC) in order to keep its time of day close to the mean solar time. -- http://en.wikipedia.org/wiki/Leap_seconds Neither of those is the *usual* astronomical meaning of precession, which refers to the top-like wobble of the north pole. Axial precession is the movement of the rotational axis of an astronomical body, whereby the axis slowly traces out a cone. -- http://en.wikipedia.org/wiki/Precession#Astronomy Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, June 07, 2013 4:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? Julian-calendar leap years are defined very simply as those that have serial numbers divisible by 4, those in the doubly infinite sequence . . . -12, -8, -4, 0, +4, +8, +12 . . . A four-year Julian-calendar cycle thus contains a mean of (3 x 365 + 1 x 366)/4 = 365.25 days. This is unsatisfactory for many terrestrial uses; precession accumulates gradually; and the seasons of the tropical year move slowly toward the beginning of the calendar year. (The Julian calendar nevertheless remains in use, in its traditional, medieval form by the Orthodox Churches and with Joseph Scaliger's 'new' epoch origin, the Gregorian date of which is -4713 November 24, by observational astronomers.) To reduce this precession the Gregorian calendar adds a second-order correction. Years are of two sorts: o centurial years, e.g., ..., -100, 0, 100,1500, 1600, 1700, 1800, 1900, 2000,... that have serial numbers divisible by 100, and o non-centurial years, all the others. Then 1) every fourth non-centurial year is a leap year and 2) every fourth centurial year is also a leap year, In other words, a non-centurial year is a leap year iff its serial number is divisible by 4; and a centurial year is a leap year iff its serial number is divisible by 400. In the upshot there are occasional intervals of seven successive non-leap years centered on a non-leap centurial year, e.g., 1897, 1898, 1899, 1900, 1901, 1902, 1903 2097, 2098, 2099, 2100, 2101, 2102, 2103, and the like. (2000 was of course a leap year.) .* A year in the 400-year Gregorian-calendar cycle thus contains a mean of (303 x 365 + 97 x 366)/400 = 365.2425 days. This is still very imperfect. It is better, yields less long-term precession than did/does the Julian calendar.. A mean tropical year, the time between successive vernal equinoxes, is shortening very slowly. Its current length is about 365.2421_9668 days. The year +3600, a centurial year having a serial number that is exactly divisible by 400, satisfies the definition of a leap year; but it will be a non-leap year by fiat in order to sop up some accumulated precession. Leap seconds deal with accumulating precession that is not dealt with effectively by the definition of the Gregorian calendar. There are many reasons for this precession, most of them classical and well understood. If you know German consult the relevant volumes of C F Gauß, Werke. If you know French, consult Laplace's Mécanique celeste. I am a little weary of correcting misapprehensions. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Here I was dealing with the precession of the vernal equinox. The position of the sun at the time of the vernal equinox is slowly shifting westward in the sky. This is a standard, not at all arcane usage. I don't think Charles Mills knows much about what he is talking about in this case, but I also don't think I want to continue this discussion. Others are of course free to do so. Instant experts, made so by consulting Wikipedia pieces, may well get considerable amusement out of agreeing or disagreeing with each other; and such exchanges do no real harm. On 6/7/13, Charles Mills charl...@mcn.org wrote: Leap seconds deal with accumulating precession that is not dealt with effectively by the definition of the Gregorian calendar. I don't *think* so. I think they deal with the rotation of the earth on its axis taking more than 24 hours, as opposed to a rotation around the sun taking more than 365 days (the February 29 and associated leap year adjustments). A clock problem as opposed to a calendar problem if you will. A leap second is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC) in order to keep its time of day close to the mean solar time. -- http://en.wikipedia.org/wiki/Leap_seconds Neither of those is the *usual* astronomical meaning of precession, which refers to the top-like wobble of the north pole. Axial precession is the movement of the rotational axis of an astronomical body, whereby the axis slowly traces out a cone. -- http://en.wikipedia.org/wiki/Precession#Astronomy Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, June 07, 2013 4:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? Julian-calendar leap years are defined very simply as those that have serial numbers divisible by 4, those in the doubly infinite sequence . . . -12, -8, -4, 0, +4, +8, +12 . . . A four-year Julian-calendar cycle thus contains a mean of (3 x 365 + 1 x 366)/4 = 365.25 days. This is unsatisfactory for many terrestrial uses; precession accumulates gradually; and the seasons of the tropical year move slowly toward the beginning of the calendar year. (The Julian calendar nevertheless remains in use, in its traditional, medieval form by the Orthodox Churches and with Joseph Scaliger's 'new' epoch origin, the Gregorian date of which is -4713 November 24, by observational astronomers.) To reduce this precession the Gregorian calendar adds a second-order correction. Years are of two sorts: o centurial years, e.g., ..., -100, 0, 100,1500, 1600, 1700, 1800, 1900, 2000,... that have serial numbers divisible by 100, and o non-centurial years, all the others. Then 1) every fourth non-centurial year is a leap year and 2) every fourth centurial year is also a leap year, In other words, a non-centurial year is a leap year iff its serial number is divisible by 4; and a centurial year is a leap year iff its serial number is divisible by 400. In the upshot there are occasional intervals of seven successive non-leap years centered on a non-leap centurial year, e.g., 1897, 1898, 1899, 1900, 1901, 1902, 1903 2097, 2098, 2099, 2100, 2101, 2102, 2103, and the like. (2000 was of course a leap year.) .* A year in the 400-year Gregorian-calendar cycle thus contains a mean of (303 x 365 + 97 x 366)/400 = 365.2425 days. This is still very imperfect. It is better, yields less long-term precession than did/does the Julian calendar.. A mean tropical year, the time between successive vernal equinoxes, is shortening very slowly. Its current length is about 365.2421_9668 days. The year +3600, a centurial year having a serial number that is exactly divisible by 400, satisfies the definition of a leap year; but it will be a non-leap year by fiat in order to sop up some accumulated precession. Leap seconds deal with accumulating precession that is not dealt with effectively by the definition of the Gregorian calendar. There are many reasons for this precession, most of them classical and well understood. If you know German consult the relevant volumes of C F Gauß, Werke. If you know French, consult Laplace's Mécanique celeste. I am a little weary of correcting misapprehensions. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA t. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
At 08:03 -0500 on 06/07/2013, Paul Gilmartin wrote about Re: Age of datasets in hours, not days?: On Fri, 7 Jun 2013 07:29:09 -0500, John McKown wrote: IMO, if IBM were to store the creation date time, then the only logical value to store is the STCKE value taken somewhere within the allocation process. It is 16 bytes in length and cannot be made any more accurate because the hardware doesn't support a greater accuracy. It is not human readable, but SO WHAT? It is easy to convert using HLASM and the STCKCONV macro. I wish that the LE people had an STCKE value to Lilian date/time conversion routine. But, again, that would be easy to write in HLASM. Does STCK still guarantee unique readings, even subsequent to the advent of STCKE? 24 hours of binary mircoseconds isn't very human readable either. And still using local time leaves wide open the hour of uncertainty every fall. It makes no sense to provide microsecond resolution while tolerating that hour of uncertainty. Were the designers even thinking? I agree. Once a year you have a 23 hour day with a 1 hour gap between 01:59:59 and 03:00:00 [one second later) and a 25 hour day (with the sequence 02:59:59 being 02:00:00 one second later with the second 02:59:00 being one second before 03:00:00). Just going GMT is simpler. So long as you store your time as HH:MM:SS, you can set MM to 60-B9 for the second 2AM hour. For the lost hour, number the hours 00,01,25,26, etc. Any hour over 24 is 22 shown as 22 more than the actual hour number (24 is reserved for 24:00:00 which is the midnight of the prior day with 00:00:00 being midnight of the indicated day). Then there is the 61 second minute (with the second before midnight of the next day being 23:59:60) when there is a leap second. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
At 14:58 -0400 on 06/07/2013, John Gilmore wrote about Re: Age of datasets in hours, not days?: The arithmetic of multiple moduli and several simultaneous cycles used to convert counter values into calendar dates always numbers seconds in the sequence 0, 1, 2, . . . , 59 It knows nothing of and cannot create a time value of the form xx xx 60. The use of a second marked as 60 is a notation to indicate the extra second in the day when a leap second occurs. That last minute of the day is 61 seconds long. This is the same as calling midnight 24:00:00 in lieu of 00:00:00 to signify it as being the last second of the day before the indicated date as opposed to the first second of that date. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
At 07:09 -0500 on 06/07/2013, Elardus Engelbrecht wrote about Re: Age of datasets in hours, not days?: John Gilmore wrote: These six bytes are thus entirely adequate to contain any unsigned elapsed- µ - sec value in a 24-hour day. Agreed. Only if all users of that 6 bytes are still using it as *un-signed* value. 2^48 - 1 = 281,474,976,710,655 2^47 - 1 = ~142,***,***,***,*** 2^46 - 1 = ~ 71,***,***,***,*** Which is much more than the needed 29,664,400,000,000 so even as signed there is enough room (the sign and the top few bits are zero). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
At 08:32 -0600 on 06/07/2013, Paul Gilmartin wrote about Re: Age of datasets in hours, not days?: Is it well specified whether the leap second is added after 23:59:59 UTC or after 23:59:59 local time if the two happen to differ? It is added just after 23:59:59 UTC (making the next second 23:59:60 UT followed by 00:00:00 UTC the next day). If you are not in UTC but GMT/UTC - 5 then the leap second is 18:59.60 local time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
At 09:20 -0700 on 06/07/2013, Ed Jaffe wrote about Re: Age of datasets in hours, not days?: As a software developer, I have had multiple occasions to process event times stored as all or part of a TOD value. For obvious reasons, end users prefer everything displayed to them in local time. Therefore, accurate reporting of these events in human-readable form requires knowledge of the locale's time zone policy going back many years (for (E)JES, we go back 10 years). For this reason, I have come to very much appreciate event times stored as local time. For example, ISPF stores member create/update time as a local time value. No conversion necessary. OTOH: It can cause a dataset that is shown has having been created/updated at 2:30 to actually be an older version of the same dataset in another directory which is shown as having been created/updated at 2:15 (ie: 45 minutes later due to the 1 hour rollback). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Charles, You should know by now that what you ask for is not always what you get! Eric Bielefeld z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Charles Mills charl...@mcn.org Subject: Re: Age of datasets in hours, not days? The rotation is not constant, and is too slow. It takes (a very little) more than 24 hours for the earth to make one rotation. What have I started!?! All I wanted to know was whether LISTCAT or the like supported dataset age granularity finer than one day! Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Charles Mills :: Sent: Friday, June 07, 2013 3:28 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Age of datasets in hours, not days? :: :: The rotation is not constant, and is too slow. It takes (a very :: little) more than 24 hours for the earth to make one rotation. :: :: What have I started!?! All I wanted to know was whether LISTCAT or the :: like supported dataset age granularity finer than one day! I don't mind you taking credit for this effluence but I don't know why you would want to. The rampant topic pollution resembles a cholera epidemic in more ways than one. I wonder if someone someday will do a thesis or dissertation on how many days a typical discussion topic continues without any discussion of the actual topic. Maybe we can create an entry in the Guinness Book of Records. There should be at least two categories: one for groups requiring registration (like this one) one for unmoderated usenet newsgroups. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
AFAIK, w/o a usermod.. NO AFAIK MVS does not keep track of creation time. The information requested can be obtained after the fact from the SMF 14/15 records. HTH. snip For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets with a creation date of n days ago. Is there any way -- not apparently with LISTCAT, but *any* way -- to get a list of conventional datasets with a creation of n *hours* ago? Does MVS keep the time of creation, or only the date? (Or, given a conventional dataset name, to determine its creation time?) /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
I think the SMF records for non vsam is the only way to know time. The time/date the SMF record was created should be close to the time/date the dataset was created/touched. I think for VSAM it is in the LISTC entry. I am not at work so I cannot validate this statement. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, June 06, 2013 8:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Age of datasets in hours, not days? For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets with a creation date of n days ago. Is there any way -- not apparently with LISTCAT, but *any* way -- to get a list of conventional datasets with a creation of n *hours* ago? Does MVS keep the time of creation, or only the date? (Or, given a conventional dataset name, to determine its creation time?) Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
Of course, if you want date/time stamps the other option (not my favorite) is to bury it in the DSN if you need real-time like information. If you can wait for the SMF data, you can pull from there. HLQ.Ttime.Ddate.etc Or create a meta database in your app that when you create a dataset, you log it. But NON Vsam does not have a lot of bells and whistles without a lot of exits and work. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 06, 2013 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? I think the SMF records for non vsam is the only way to know time. The time/date the SMF record was created should be close to the time/date the dataset was created/touched. I think for VSAM it is in the LISTC entry. I am not at work so I cannot validate this statement. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, June 06, 2013 8:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Age of datasets in hours, not days? For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets with a creation date of n days ago. Is there any way -- not apparently with LISTCAT, but *any* way -- to get a list of conventional datasets with a creation of n *hours* ago? Does MVS keep the time of creation, or only the date? (Or, given a conventional dataset name, to determine its creation time?) Charles -- 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
Re: Age of datasets in hours, not days?
Thanks, all. Yeah, I know about putting a code into the name. There are of course complications to doing that. I really want something like LISTCAT so SMF is not the answer. I will pursue other approaches. (Yes, I should have said non-VSAM.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 06, 2013 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? Of course, if you want date/time stamps the other option (not my favorite) is to bury it in the DSN if you need real-time like information. If you can wait for the SMF data, you can pull from there. HLQ.Ttime.Ddate.etc Or create a meta database in your app that when you create a dataset, you log it. But NON Vsam does not have a lot of bells and whistles without a lot of exits and work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
TSF (Total Storage Facility) from Estorian will provide that function. On the other hand if you merely want to track the life of a dataset, DAF from the CBT tape is a good option. Thank You, Dave O'Brien NIH Contractor From: Lizette Koehler [stars...@mindspring.com] Sent: Thursday, June 06, 2013 12:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? Of course, if you want date/time stamps the other option (not my favorite) is to bury it in the DSN if you need real-time like information. If you can wait for the SMF data, you can pull from there. HLQ.Ttime.Ddate.etc Or create a meta database in your app that when you create a dataset, you log it. But NON Vsam does not have a lot of bells and whistles without a lot of exits and work. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 06, 2013 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Age of datasets in hours, not days? I think the SMF records for non vsam is the only way to know time. The time/date the SMF record was created should be close to the time/date the dataset was created/touched. I think for VSAM it is in the LISTC entry. I am not at work so I cannot validate this statement. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, June 06, 2013 8:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Age of datasets in hours, not days? For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets with a creation date of n days ago. Is there any way -- not apparently with LISTCAT, but *any* way -- to get a list of conventional datasets with a creation of n *hours* ago? Does MVS keep the time of creation, or only the date? (Or, given a conventional dataset name, to determine its creation time?) Charles -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
On Thu, 6 Jun 2013 11:59:13 -0400, Charles Mills wrote: For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets with a creation date of n days ago. Is there any way -- not apparently with LISTCAT, but *any* way -- to get a list of conventional datasets with a creation of n *hours* ago? Does MVS keep the time of creation, or only the date? (Or, given a conventional dataset name, to determine its creation time?) Don't overreach. Next someone will want a granularity of seconds, and be confronted with leap second ambiguities. Does the age reported by LISTCAT change at midnight GMT? Local time? Other (specify)? Almost equivalently, is the recorded creation date GMT or Local? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Age of datasets in hours, not days?
I think all is local. Like race horses on January 1, all datasets appear to have a birthday at midnight local. A dataset created at 23:59 is one day old at 00:01. Charles Composed on a mobile: please excuse my brevity Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 6 Jun 2013 11:59:13 -0400, Charles Mills wrote: For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets with a creation date of n days ago. Is there any way -- not apparently with LISTCAT, but *any* way -- to get a list of conventional datasets with a creation of n *hours* ago? Does MVS keep the time of creation, or only the date? (Or, given a conventional dataset name, to determine its creation time?) Don't overreach. Next someone will want a granularity of seconds, and be confronted with leap second ambiguities. Does the age reported by LISTCAT change at midnight GMT? Local time? Other (specify)? Almost equivalently, is the recorded creation date GMT or Local? -- gil -- 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
Re: Age of datasets in hours, not days?
On 06/06/2013 12:06 PM, Paul Gilmartin wrote: On Thu, 6 Jun 2013 11:59:13 -0400, Charles Mills wrote: For conventional MVS datasets, LISTCAT ... CREATION(n) gives me all datasets with a creation date of n days ago. Is there any way -- not apparently with LISTCAT, but *any* way -- to get a list of conventional datasets with a creation of n *hours* ago? Does MVS keep the time of creation, or only the date? (Or, given a conventional dataset name, to determine its creation time?) Don't overreach. Next someone will want a granularity of seconds, and be confronted with leap second ambiguities. Does the age reported by LISTCAT change at midnight GMT? Local time? Other (specify)? Almost equivalently, is the recorded creation date GMT or Local? -- gil Creation date and last-reference date is based on local time and date. Dataset last-reference age in days affecting eligibility for HSM migration bumps at midnight local time (which means a 1-day-old dataset might actually only be seconds old just after midnight). -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
