Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
While questionably STCKE will be better than STCK (depending on the use), the correct solution is to use some kind of unbiased value with an optional displacement. True, STCK(E) is easier, but it not a good value to be hardened for long term use. One MUST plan for the future. On Wed, 15 May 2013 06:54:01 -0400 John Gilmore jwgli...@gmail.com wrote: :Earlier this week, on another list, I encountered someone who was :proposing to use STCK TOD values in a new system. :He should of course have chosen STCKE values instead. At 23:58:43 on :17 September 2042 the IBM mainframe TOD clock, 64-bit STCK value will :overflow. STCKE values do not have this defect; the portions of them :that are incremented are unsigned 14-byte, 8 x 14 = 112-bit values; :and 2^112 - 1 is an adequately large number. :The slogan Do not reinvent the wheel sounds virtuous, at worst :innocuous. In fact its use is an all but infallible indicator of :sanctimony mixed with sloth. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Thu, 16 May 2013 09:36:55 +0300, Binyamin Dissen wrote: While questionably STCKE will be better than STCK (depending on the use), the correct solution is to use some kind of unbiased value with an optional displacement. True, STCK(E) is easier, but it not a good value to be hardened for long term use. Binyamin, I'm having a hard time understanding what you mean. Perhaps you'd care to explain. Why is it questionable that STCKE is better than STCK? What do you mean by an unbiased value with an optional displacement? Why doesn't STCKE provide a good value for long term use? One MUST plan for the future. Yes. Is your concern that the ETOD is only good for 36,000 years? -- Thanks, Tom Marchant On Wed, 15 May 2013 06:54:01 -0400 John Gilmore jwgli...@gmail.com wrote: :Earlier this week, on another list, I encountered someone who was :proposing to use STCK TOD values in a new system. :He should of course have chosen STCKE values instead. At 23:58:43 on :17 September 2042 the IBM mainframe TOD clock, 64-bit STCK value will :overflow. STCKE values do not have this defect; the portions of them :that are incremented are unsigned 14-byte, 8 x 14 = 112-bit values; :and 2^112 - 1 is an adequately large number. :The slogan Do not reinvent the wheel sounds virtuous, at worst :innocuous. In fact its use is an all but infallible indicator of :sanctimony mixed with sloth. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Thu, 16 May 2013 09:36:55 +0300, Binyamin Dissen wrote: While questionably STCKE will be better than STCK (depending on the use), the correct solution is to use some kind of unbiased value with an optional displacement. True, STCK(E) is easier, but it not a good value to be hardened for long term use. One MUST plan for the future. Any fixed-length representation can theoretically encounter limits of range or precison or both. Among fixed-length representations, STCKE is 49% good: it bears an affine relationship to TAI and has sufficient precision for practical uses, and sufficient range for practical uses in the present and future, but not in the past. If I were to consider a representation of unlimited range and precision, I'd first think of an XML representation of TAI in decimal display, but beware of buffer overflows. What would you consider unbiased? On Wed, 15 May 2013 11:06:02 -0400, John Gilmore wrote: TOD clocks, incremented counters in general, are by definition unsigned. Moreover, with the exception of some few astronomical ones, we do not know the times of past events, even quite recent ones with precision. Few indeed. In Classical times the offset can be hours, with considerable uncertainty. the elephant in the room: http://en.wikipedia.org/wiki/%CE%94T On Wed, 15 May 2013 11:27:47 -0500, John McKown wrote: Rather than being signed, IBM _could_ move the epoch back. ... What is the etiology of this irrational dread of negative numbers? Must clock values be deemed cardinal numbers? I had thought that considering the STCKE value as signed would introduce no incompatibilities; it still seems the most likely to be compatible. But an IBM employee (and others?) have said here that this would be incompatible with existing use. What? I can only imagine setting the Clock Comparator Register to all ones for an interval that is unlikely to expire between IPLs. (Are there nowadays both 64-bit and 112-bit Clock Comparator registers? Are there any GUPI interfaces to the 64-bit Comparator that must be preserved?) --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Thu, 16 May 2013 07:27:11 -0500 Tom Marchant m42tom-ibmm...@yahoo.com wrote: :On Thu, 16 May 2013 09:36:55 +0300, Binyamin Dissen wrote: :While questionably STCKE will be better than STCK (depending on the use), the :correct solution is to use some kind of unbiased value with an optional :displacement. True, STCK(E) is easier, but it not a good value to be hardened :for long term use. :Binyamin, :I'm having a hard time understanding what you mean. Perhaps you'd care to explain. :Why is it questionable that STCKE is better than STCK? What are you using it for? If to measure short intervals, does the (E) form provide a serious benefit? :What do you mean by an unbiased value with an optional displacement? A GMT/UTC value plus a displacement to give the current local time. :Why doesn't STCKE provide a good value for long term use? If used against the past, can one be sure of the various leap values applied? Is it GMT, UTC or LOCAL? :One MUST plan for the future. :Yes. Is your concern that the ETOD is only good for 36,000 years? No, that the format as a number of intervals since a epoch is not a definite value unless one knows everything that went on at that time and since. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OE Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On 2013-05-15 12:49:14 Tom Marchant wrote: On Wed, 15 May 2013 11:27:47 -0500, John McKown wrote: Rather than being signed, IBM _could_ move the epoch back. Remember when some shops would post here every time the clocks changed back in the fall? They were running with local=GMT and would have to keep their IMS systems down for an hour so that they wouldn't have duplicate time stamps. If IBM were to change the epoch, customers would have to keep them down for a lot longer In my opinion, invention of Daylight Savings Time was the work of the Devil. :-) Leslie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Thu, 16 May 2013 11:23:08 -0400, John Gilmore wrote: ... of STCK[E] values: It is usable 'against the past' only after midnight 1899 December 31. The question whether it is GMT, UTC, or LOCAL misses the point. It is none of these. It is best thought of as a coarse-grained TIA-like value. No 'leap values' have been or should properly be applied to it. Its conversion into TUC, GD, or JD values does involve applying [different] leap values, but this is straightforward both for leap years and leap seconds. If it's straightforward, why doesn't STCKCONV do it, or at least state in documentation that it doesn't. The table of offsets is readily availabli in P[0r]Op, so IBM knows the information. It is also possible, indeed easy, to devise an STCKE-based signed timestamp. To do so, one needs to sacrifice the high-order bit, which will in any cased be unset for about 18,000 years. Times before midnight 1899 December 31 can then be represented in the usual way as twos-complement values. That's two votes,. But IBM has stated that would introduce incompatibilities, but hasn't been more specific. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Thu, 16 May 2013 11:30:06 -0500, Paul Gilmartin wrote: On Thu, 16 May 2013 11:23:08 -0400, John Gilmore wrote: It is also possible, indeed easy, to devise an STCKE-based signed timestamp. To do so, one needs to sacrifice the high-order bit, which will in any cased be unset for about 18,000 years. Times before midnight 1899 December 31 can then be represented in the usual way as twos-complement values. That's two votes,. But IBM has stated that would introduce incompatibilities, but hasn't been more specific. Perhaps because the (E)TOD clock value is documented as an unsigned integer. Any code that performs arithmetic or comparisons as unsigned data would get surprising results if there were negative values. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
Earlier this week, on another list, I encountered someone who was proposing to use STCK TOD values in a new system. He should of course have chosen STCKE values instead. At 23:58:43 on 17 September 2042 the IBM mainframe TOD clock, 64-bit STCK value will overflow. STCKE values do not have this defect; the portions of them that are incremented are unsigned 14-byte, 8 x 14 = 112-bit values; and 2^112 - 1 is an adequately large number. The slogan Do not reinvent the wheel sounds virtuous, at worst innocuous. In fact its use is an all but infallible indicator of sanctimony mixed with sloth. 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: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Wed, 15 May 2013 06:54:01 -0400, John Gilmore wrote: Earlier this week, on another list, I encountered someone who was proposing to use STCK TOD values in a new system. Circa 1987, in a design meeting I advocated reserving a 4-digit field for a date. I was sneered at because the TIME macro wouldn't support it. He should of course have chosen STCKE values instead. At 23:58:43 on 17 September 2042 the IBM mainframe TOD clock, 64-bit STCK value will +/- leap seconds. IAT? UTC? UT1? ... overflow. STCKE values do not have this defect; the portions of them that are incremented are unsigned 14-byte, 8 x 14 = 112-bit values; and 2^112 - 1 is an adequately large number. They should have made it signed. Year 1899 seems to me to have more practical use than 19,000. The slogan Do not reinvent the wheel sounds virtuous, at worst innocuous. In fact its use is an all but infallible indicator of sanctimony mixed with sloth. I once heard, Don't reinvent the flat tire. (The topic was the VM/CMS Shared File System.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
TOD values are, conceptually, most like IAT ones. Specialization/adulteration is DIY. TOD clocks, incremented counters in general, are by definition unsigned. Moreover, with the exception of some few astronomical ones, we do not know the times of past events, even quite recent ones with precision. Krakatoa, for example, 'began to erupt' on 1883 May 20th, but more precision turns out to be elusive. We are told that Anne Boleyn was executed at 0800 on the morning of 1536 May 19 (O.S.), but I have no confidence in this round exactitude. For past events [often negative] proleptic dates usually suffice and must usually suffice. It is, for example, enough to know that the epoch origin of the Kali Yuga calendar has the GD, Gregorian Day [number], -1,132,958. Signed fullword GDs can represent dates ±5.8 million years about the Gregorian calendar's epoch origin. That is usually enough; and if, exceptionally it is not, there are signed doublewords available. 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: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
Rather than being signed, IBM _could_ move the epoch back. I don't see any need. In fact, personally, I would not use STCKE values. I'd use something like true Julian dates/times (like the astronomers use), or perhaps Lilian dates (date only, no time) since there some nice LE subroutines to format them for display. CEEGMT will get the TOD clock value, returning it in Lilian format date integer a 64-bit double floating point number of second from 00:00:00 14 October 1582 (not counting any leap seconds). CEEGMTO gets the __current__ offset from GMT to local. Which means it is not useful for historical dates, in general. CEEDATM will convert the 2nd output (64 bit float number) from CEEGMT to a printable format (user defined). CEEDATE will convert the Lilian date seconds (1st output) to a display value. So CEEGMT seems, to me, to be a viable way to go. And I am aware that many view LE as devil's brew. But I, personally, have at least gotten used to it. If somebody wanted to convert an STCKE saved value to printable, I would guess a reasonable way would be to use the CONVTOD macro to convert to printable. I might even then go to CEEGMT format via CEESECS to convert this to Lilian seconds (64 bit float) and store that. Or pop it into a DB2 date/time field. If I had DB2, that is grin/. On Wed, May 15, 2013 at 10:06 AM, John Gilmore jwgli...@gmail.com wrote: TOD values are, conceptually, most like IAT ones. Specialization/adulteration is DIY. TOD clocks, incremented counters in general, are by definition unsigned. Moreover, with the exception of some few astronomical ones, we do not know the times of past events, even quite recent ones with precision. Krakatoa, for example, 'began to erupt' on 1883 May 20th, but more precision turns out to be elusive. We are told that Anne Boleyn was executed at 0800 on the morning of 1536 May 19 (O.S.), but I have no confidence in this round exactitude. For past events [often negative] proleptic dates usually suffice and must usually suffice. It is, for example, enough to know that the epoch origin of the Kali Yuga calendar has the GD, Gregorian Day [number], -1,132,958. Signed fullword GDs can represent dates ±5.8 million years about the Gregorian calendar's epoch origin. That is usually enough; and if, exceptionally it is not, there are signed doublewords available. 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 -- 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: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Wed, 15 May 2013 11:27:47 -0500, John McKown wrote: Rather than being signed, IBM _could_ move the epoch back. Remember when some shops would post here every time the clocks changed back in the fall? They were running with local=GMT and would have to keep their IMS systems down for an hour so that they wouldn't have duplicate time stamps. If IBM were to change the epoch, customers would have to keep them down for a lot longer -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On Wed, 15 May 2013 13:08:32 -0500, John McKown wrote: Actually, if the epoch were moved BACK in time, then the TOD value would need to be increased ... Duh My mistake. Thanks for the correction. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On 15 May 2013 14:08, John McKown john.archie.mck...@gmail.com wrote: Yeah, well I didn't say it was a _good_ idea grin/. Actually, if the epoch were moved BACK in time, then the TOD value would need to be increased to keep the date the same. Which is just what happened with MVT and MVS; the epoch was changed from 1960 to 1900. Though there was, of course, nothing much to force anyone to use either the old or the new IBM standard. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
It’s inexplicable that the 1990s saw new applications developed with Y2K doom built in. This is especially true that the first Y2K problem I know of occurred in 1970 (30-year contracts) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
Back to the Future -- Don't Reinvent Mainframe Wheels Passing on System z wisdom pays off for you and your organization http://ow.ly/kBl9Z or http://destinationz.org/Mainframe-Solution/Trends/Pass-on-System-z-Wisdom.aspx -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
Gabe Goldberg wrote: Back to the Future -- Don't Reinvent Mainframe Wheels Passing on System z wisdom pays off for you and your organization http://destinationz.org/Mainframe-Solution/Trends/Pass-on-System-z-Wisdom.aspx Thanks. Very very interesting! Oh, that brings me memories... ;-) Some curiousity questions/answers after reading that above web-site: Don't update the running system—not even by accident. If you're not sure why, ask a scarred veteran. Yes! Do it! Do it!! Do it!!! Any platform will do! And live with the scars! ;-D (Side note: even by changing your LLA to use another set of LLA (SETPROG LNKLST,UPDATE=* for example) for some fun which may results in an unexpected IPL. Good fun especially when that library contains some bad assembled mods!) Regularly shut down and reIPL (or reboot, or restart, or whatever's necessary on non-mainframe platforms) for practice, to make it a routine procedure and to verify documentation. Don’t learn how to do this under pressure. Still our operators don't learn... If it was in my powers, I will give them 2 or 3 changes only to learn, but no, those unions have more powers... :-( Periodically test backup; never-tested backup procedures are too often discovered to be write only. Really? One of our Unix sys admin discovered years ago just by that, that their backup procedures were, ahem, 'defective'. Good for laughs if you're not part of that disaster... grin (Those bastards lost some costly 'important' files owned by users. Their bosses were not that impressed... ouch... lots of ouch... ) Don't test with live data. One of our users did that little nice stunt and the next day they had to do a roll-back on their prod DB... Blame shifting got a new meaning and they see the value of a sandbox! ;-D Use standard system services rather than developing custom interfaces. I use for example 'standard IBM utilities' to justify my audit work (RACF for example). 'Home written things' will not work in audits. Trust me on that one. Use customization facilities but avoid changing what vendors send; that increases migration burdens and pitfalls. WARNING: war story I could *not* avoid changing what vendors send. One of IBM's product (which shall stay nameless) have changed their security modules (in their JCL) to be REUS, not NOREUS from one version to the next, but the documentation stayed the SAME! It caused me pain on the painframe. So I had to advise to change that one stupid Assembler/Binder job setting to what it was on the previous version. All testing then went successfull and we could go on with the installation. That poor support person has documented it properly for future reference. No sweat next time hopefully... ;-) It’s inexplicable that the 1990s saw new applications developed with Y2K doom built in. Are there any products which are STILL carrying that junk after 12+ years? Geez, I will faint if I see such code [1]... ;-) Any comments on that web-site? ;-) Groete / Greetings Elardus Engelbrecht [1] - You still need to be careful to parse out the date fields in SMF fields like SMFxDTE to accomodate that Y2K junk (0cyydddF where c is an ugly artifact which had to be replaced by that thing 'century'. Yuck, but this is backward compatibility at its best and now, I'm fainting... ;-D ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
Yup. Especially robust when they claimed 'we can replace all mainframe functions' for $25K. Then 3 server upgrades and 8 new personnel totaling over $1M; drop the database on Friday before new fundraiser. Backups not usable. When smoke cleared, junked the whole department. In a message dated 5/6/2013 3:50:07 P.M. Central Daylight Time, elardus.engelbre...@sita.co.za writes: Really? One of our Unix sys admin discovered years ago just by that, that their backup procedures were, ahem, 'defective'. Good for laughs if you're not part of that disaster... grin (Those bastards lost some costly 'important' files owned by users. Their bosses were not that impressed... ouch... lots of ouch... ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
