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.com>wrote: > 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
