It already is. It's in Kansas.
--
This email message and any accompanying materials may contain proprietary,
privileged and confidential information of CIT Group Inc. or its subsidiaries
or affiliates (collectively, "CIT"
Gerhard Postpischil wrote:
| And Toronto will be a U.S. city?
I was reliably informed that 'Toronto' has for some reason always been
problematic; a precursor of Watson, reasoning by phonetic analogy with
'Taranto', moved it to Italy in a slightly different context.
--jg
On 1/31/12, Gerhard Po
On 1/31/2012 3:48 PM, Ken Porowski wrote:
Watson should be answering all the questions by then .
And Toronto will be a U.S. city?
Gerhard Postpischil
Bradford, VT
--
For IBM-MAIN subscribe / signoff / archive access instruc
On Tue, Jan 31, 2012 at 3:03 PM, Paul Gilmartin wrote:
> On Tue, 31 Jan 2012 15:48:16 -0500, Ken Porowski wrote:
>
>>Watson should be answering all the questions by then .
>>
> Siri.
>
> -- gil
Like this?
http://www.funnyordie.com/videos/2bcb35e787/cockblocked-by-siri
--
Mike A Schwab, Springfiel
Correction: Watson should be giving all the 'correct' answers by then.
--
This email message and any accompanying materials may contain proprietary,
privileged and confidential information of CIT Group Inc. or its subsidia
On Tue, 31 Jan 2012 15:48:16 -0500, Ken Porowski wrote:
>Watson should be answering all the questions by then .
>
Siri.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu
il address.
--
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Phil Smith
Sent: Tuesday, January 31, 2012 2:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] TOD clock format
Barry Merrill wrote:
> 6. I pl
Barry Merrill wrote:
> 6. I plan to be here to observe the wrap; I'll be 101+six months in Sept
2042.
And MXG will still be running, I'm sure! What version will it be by then? Will
the operating system still be called "z/OS"? If so, will it be Version 1
Release 43? What will the hardware be know
s in Sept
> 2042.
>
> Barry Merrill
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of Charles Mills
> Sent: Tuesday, January 31, 2012 11:58 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: TOD clock format
&g
AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TOD clock format
> the programs that digest the records can actually deal with that
If I had to venture a guess I would guess that 64-bit TOD clock fields will
still be around post-2042 and programs will be using windowing techniques to
decide if a particula
seemingly forever.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Phil Smith
Sent: Tuesday, January 31, 2012 7:08 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TOD clock format
John Gilmore wrote:
>There is thus no excuse f
Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Phil Smith
Sent: Tuesday, January 31, 2012 7:08 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TOD clock format
John Gilmore wrote:
>There is thus no excuse for any use of an STCK instruction in NEW code.
>Old code is a different matte
John Gilmore wrote:
>There is thus no excuse for any use of an STCK instruction in NEW
>code. Old code is a different matter, If it is judged that there is
>NO possibility that it will still be in use in 2042, STCKs in it need
>not be replaced. Otherwise they should be.
How about code that's ge
In
,
on 01/30/2012
at 03:27 PM, Phil Smith said:
>It's been a while since I did an STCK and looked at the results. ISTR
>that the last five or so nibbles were always zero;
Maybe on a really old, slow machine. IAC, the basics haven't changed;
each bit ot the TOD clock represents the same durat
On Mon, 30 Jan 2012 15:27:06 -0800, Phil Smith wrote:
>I looked at PofOp and didn't see it (but then, it's not the
>most accessible volume any more - remember the old days,
>when it was what, 200 pages?).
The -7 edition of the System/360 POO is on bitsavers. It
is 199 pages and you won't find
Regrettably, the current PrOp in not specific about the time horizon
of the STCK instruction.
At 23:58:43 on 17 September 2042 the IBM mainframe TOD clock, 64-bit
STCK value overflows.
STCKE values do not have this defect. Effectively, they are 14-byte,
8 x 14 = 112-bit [unsigned] values. (The
On Mon, 30 Jan 2012 19:54:06 -0500, Tony Harminc wrote:
>
>Even machines with the traditional 64-bit TOD clock guaranty that
>different values will be obtained from two executions of STCK on one
>or different CPUs. You cannot issue STCKs fast enough to obtain
>duplicate values. Or rather, the machi
On 30 January 2012 18:27, Phil Smith wrote:
> It's been a while since I did an STCK and looked at the results. ISTR that
> the last five or so nibbles were always zero; now they aren't.
Five zero nibbles suggest quite a slow CPU. On current hardware, a
number of bits to the right of position 51
Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Phil Smith
Sent: Monday, January 30, 2012 3:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: TOD clock format
It's been a while since I did an STCK and looked at the results. ISTR that
the last five or so nibbles were always zero; now
It's been a while since I did an STCK and looked at the results. ISTR that the
last five or so nibbles were always zero; now they aren't. I assume that's
added granularity to reduce repeated timestamps from STCKs close together (on
the same processor), though still perhaps not enough to avoid th
20 matches
Mail list logo
