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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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 /
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.
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
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
18 matches
Mail list logo
