info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TOD clock format
1,358 views
Skip to first unread message
Phil Smith
Jan 30, 2012, 11:32:39 PM1/30/12
to
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 the need for STCKE in critical codepaths.
Anyway, does anyone have a machine-readable copy of the current "rules" for STCK? 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?).
Thanks,
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: INFO IBM-MAIN
Anyway, does anyone have a machine-readable copy of the current "rules" for STCK? 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?).
Thanks,
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: INFO IBM-MAIN
Charles Mills
Jan 31, 2012, 12:32:12 AM1/31/12
to
You mean:
The current value of bits 0-63 of the TOD clock is
stored in the eight-byte field designated by the sec-
ond-operand address, provided the clock is in the
set, stopped, or not-set state.
When the clock is stopped, zeros are stored in positions
to the right of the rightmost bit position that is
incremented when the clock is running. For STORE
CLOCK, when the value of a running clock is stored,
nonzero values may be stored in positions to the right
of the rightmost incremented bit; this is to ensure that
a unique value is stored. For STORE CLOCK FAST,
when the value of a running clock is stored, bits to
the right of the rightmost bit that is incremented are
stored as zeros.
Zeros are stored at the operand location when the
clock is in the error state or the not-operational state.
The quality of the clock value stored by the instruction
is indicated by the resultant condition-code setting.
For STORE CLOCK, a serialization function is performed
before the value of the clock is fetched and
again after the value is placed in storage.
Resulting Condition Code:
0 Clock in set state
1 Clock in not-set state
2 Clock in error state
3 Clock in stopped state or not-operational state
Program Exceptions:
. Access (store, operand 2)
. Operation (STCKF, if the store-clock-fast facility
is not installed)
Programming Notes:
1. Bit position 31 of the clock is incremented every
1.048576 seconds; hence, for timing applications
involving human responses, the leftmost clock
word may provide sufficient resolution.
2. Condition code 0 normally indicates that the
clock has been set by the control program.
Accordingly, the value may be used in elapsedtime
measurements and as a valid time-of-day
and calendar indication. Condition code 1 indicates
that the clock value is the elapsed time
since the power for the clock was turned on. In
this case, the value may be used in elapsed-time
measurements but is not a valid time-of-day indication.
Condition codes 2 and 3 mean that the
value provided by STORE CLOCK cannot be
used for time measurement or indication.
3. Condition code 3 indicates that the clock is in
either the stopped state or the not-operational
state. These two states can normally be distinguished
because an all-zero value is stored
when the clock is in the not-operational state.
4. If a problem program written for z/Architecture is
to be executed also on a system in the System/
370 mode, then the program should take into
account that, in the System/370 mode, the value
stored when the condition code is 2 is not necessarily
zero.
5. Two executions of STORE CLOCK FAST, or an
execution of STORE CLOCK FAST and STORE
CLOCK, either on the same or different CPUs,
do not necessarily return different values of the
clock if the clock is running. Thus, the values
returned by STORE CLOCK FAST do not necessarily
indicate the correct sequence of execution
of the instruction by one or more CPUs.
6. When the TOD-clock-steering facility is installed,
and assuming a valid operating system, then, for
the problem program, the TOD clock is always in
the set state and there is no need to test the condition
code after issuing STORE CLOCK or
STORE CLOCK FAST.
Useful site: http://www.longpelaexpertise.com.au/toolsTOD.php
Charles
The current value of bits 0-63 of the TOD clock is
stored in the eight-byte field designated by the sec-
ond-operand address, provided the clock is in the
set, stopped, or not-set state.
When the clock is stopped, zeros are stored in positions
to the right of the rightmost bit position that is
incremented when the clock is running. For STORE
CLOCK, when the value of a running clock is stored,
nonzero values may be stored in positions to the right
of the rightmost incremented bit; this is to ensure that
a unique value is stored. For STORE CLOCK FAST,
when the value of a running clock is stored, bits to
the right of the rightmost bit that is incremented are
stored as zeros.
Zeros are stored at the operand location when the
clock is in the error state or the not-operational state.
The quality of the clock value stored by the instruction
is indicated by the resultant condition-code setting.
For STORE CLOCK, a serialization function is performed
before the value of the clock is fetched and
again after the value is placed in storage.
Resulting Condition Code:
0 Clock in set state
1 Clock in not-set state
2 Clock in error state
3 Clock in stopped state or not-operational state
Program Exceptions:
. Access (store, operand 2)
. Operation (STCKF, if the store-clock-fast facility
is not installed)
Programming Notes:
1. Bit position 31 of the clock is incremented every
1.048576 seconds; hence, for timing applications
involving human responses, the leftmost clock
word may provide sufficient resolution.
2. Condition code 0 normally indicates that the
clock has been set by the control program.
Accordingly, the value may be used in elapsedtime
measurements and as a valid time-of-day
and calendar indication. Condition code 1 indicates
that the clock value is the elapsed time
since the power for the clock was turned on. In
this case, the value may be used in elapsed-time
measurements but is not a valid time-of-day indication.
Condition codes 2 and 3 mean that the
value provided by STORE CLOCK cannot be
used for time measurement or indication.
3. Condition code 3 indicates that the clock is in
either the stopped state or the not-operational
state. These two states can normally be distinguished
because an all-zero value is stored
when the clock is in the not-operational state.
4. If a problem program written for z/Architecture is
to be executed also on a system in the System/
370 mode, then the program should take into
account that, in the System/370 mode, the value
stored when the condition code is 2 is not necessarily
zero.
5. Two executions of STORE CLOCK FAST, or an
execution of STORE CLOCK FAST and STORE
CLOCK, either on the same or different CPUs,
do not necessarily return different values of the
clock if the clock is running. Thus, the values
returned by STORE CLOCK FAST do not necessarily
indicate the correct sequence of execution
of the instruction by one or more CPUs.
6. When the TOD-clock-steering facility is installed,
and assuming a valid operating system, then, for
the problem program, the TOD clock is always in
the set state and there is no need to test the condition
code after issuing STORE CLOCK or
STORE CLOCK FAST.
Useful site: http://www.longpelaexpertise.com.au/toolsTOD.php
Charles
Tony Harminc
Jan 31, 2012, 1:09:21 AM1/31/12
to
On 30 January 2012 18:27, Phil Smith <ph...@voltage.com> 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
> 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.
number of bits to the right of position 51 (the microsecond bit) are
typically seen to increment in trace entries and the like.
> 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 the need for STCKE in critical codepaths.
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 machine will do what it has to, even
to the extent of slowing your program, so that things come out as
documented. Doubtless for this reason, Store Clock Fast (STCKF)
exists. How STCK and STCKE interact with STCKF is more subtle, but
allows for performance with predictability.
> Anyway, does anyone have a machine-readable copy of the current "rules" for STCK? 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?).
However the clock "rules" are in the current 1300+ page monster, and I
think not too inaccessible, for all the impracticality of bedtime
reading of the paper version. Chapter 4. Control ->Timing
->Time-of-Day-Clock -> Setting and Inspecting the Clock is the place
to start. Just over a page for the rules, and followed by some very
good notes.
Tony H.
Paul Gilmartin
Jan 31, 2012, 1:56:24 AM1/31/12
to
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 machine will do what it has to, even
>to the extent of slowing your program, so that things come out as
>documented. Doubtless for this reason, Store Clock Fast (STCKF)
>exists. How STCK and STCKE interact with STCKF is more subtle, but
>allows for performance with predictability.
>
Long ago, IIRC, the PoOp (PrOp) said that each CPU in a system had
>
>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 machine will do what it has to, even
>to the extent of slowing your program, so that things come out as
>documented. Doubtless for this reason, Store Clock Fast (STCKF)
>exists. How STCK and STCKE interact with STCKF is more subtle, but
>allows for performance with predictability.
>
its own TOD clock. A wizard told me that this was to ensure fault
tolerance, and that there was some horrendous logic to keep all
synchronized or report an error (bad CC? machine check?) if they
fell out-of-sync. And that the lowest bits were CPU-specific (Processor
ID?) to ensure uniqueness.
Nowadays, the PoOp (PrOp) says that a single (E)TOD clock serves
all processors in a system.
-- gil
John Gilmore
Jan 31, 2012, 3:27:34 AM1/31/12
to
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 rightmost two bytes of the
full sixteen-byte value ensure uniqueness when there are multiple TOD
clocks in an environment, but they are not part of the TOD value
proper.)
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.
--jg
--
John Gilmore, Ashland, MA 01721 - USA
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 rightmost two bytes of the
full sixteen-byte value ensure uniqueness when there are multiple TOD
clocks in an environment, but they are not part of the TOD value
proper.)
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.
--jg
--
John Gilmore, Ashland, MA 01721 - USA
Tom Marchant
Jan 31, 2012, 3:36:50 AM1/31/12
to
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
>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?).
is 199 pages and you won't find a TOD clock in it.
The -4 edition of the System/370 POO, dated September,
1974 is 329 pages.
Regardless, there is a lot to a z/Architecture processor and
I disagree that the POO is a difficult document.
--
Tom Marchant
Shmuel Metz , Seymour J.
Jan 31, 2012, 1:18:48 PM1/31/12
to
In
<B870629719727B4BA82A6...@hqmailsvr01.voltage.com>,
on 01/30/2012
each bit ot the TOD clock represents the same duration. With faster
processors more low order bits are incremented to provide better
granularity. Even the old interval timer on the S/360 had that kind of
stability.
--
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)
<B870629719727B4BA82A6...@hqmailsvr01.voltage.com>,
on 01/30/2012
at 03:27 PM, Phil Smith <ph...@VOLTAGE.COM> 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;
>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;
each bit ot the TOD clock represents the same duration. With faster
processors more low order bits are incremented to provide better
granularity. Even the old interval timer on the S/360 had that kind of
stability.
--
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)
Phil Smith
Jan 31, 2012, 3:12:33 PM1/31/12
to
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 generating SMF records? That's what we're dealing with here. Yeah, 2042 might be an issue, but the programs that digest the records can actually deal with that (and will have to, or SMF in general will by then).
>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.
...phsiii
Charles Mills
Jan 31, 2012, 4:29:10 PM1/31/12
to
I suppose a perfectly prudent programmer might use STCK -- in case anyone is
not aware, SMF records contain multiple fields that can only be in 64-bit
STCK format -- but put a warning message in his program that started popping
up around 2039.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Phil Smith
not aware, SMF records contain multiple fields that can only be in 64-bit
STCK format -- but put a warning message in his program that started popping
up around 2039.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Phil Smith
Sent: Tuesday, January 31, 2012 7:08 AM
To: IBM-...@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 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 generating SMF records? That's what we're dealing with
here. Yeah, 2042 might be an issue, but the programs that digest the records
can actually deal with that (and will have to, or SMF in general will by
then).
To: IBM-...@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 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 generating SMF records? That's what we're dealing with
here. Yeah, 2042 might be an issue, but the programs that digest the records
can actually deal with that (and will have to, or SMF in general will by
then).
Charles Mills
Jan 31, 2012, 6:01:33 PM1/31/12
to
> 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 particular 64-bit TOD value is a date and time in 1901 or a date
and time in 2043 (with 2043 being a lot more likely, of course). The problem
is of course somewhat more complicated than Y2K because the time and entire
date will have to be adjusted as well as the year.
2042 sounds like it is a long way away, but 2000 seemed like it was a long
way away in 1970. "Are you kidding? We won't still be using my COBOL program
in 2000 -- computers will just be reading our minds by then."
Actually, I guess, the biggest problem is not that programs endure -- it is
that record layouts (like SMF) and control block formats (like the 24-bit
DCB) endure seemingly forever.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Phil Smith
Sent: Tuesday, January 31, 2012 7:08 AM
To: IBM-...@bama.ua.edu
Subject: Re: TOD clock format
Barry Merrill
Jan 31, 2012, 6:49:27 PM1/31/12
to
1. Dates beyond 2042 are nearly possible, since tape retention can be 30
years.
2. I have seen IMS APARs that indicate STCKE values are now stored in some
control blocks.
3. The TODSTAMP wrap only impacts SMF record fields that are in TOD format;
the SMFSTAMP
format has no wrap because it's date is a separate 4-byte part of the
8-byte field,
and the date contains the century bit, which won't wrap for 254
centuries.
4. TODSTAMP has microsecond resolution, while SMFSTAMP is limited to 10
milliseconds,
so TODSTAMP is (IMO) preferred in new SMF records, except for the SMFTIME
field in
the header that still needs to be SMFSTAMP format.
5. In MXG processing members, I observed these counts:
IBM SMF records Vendor SMF records Total Instances
TODSTAMPs 651 667 1318
SMFSTAMPs 147 345 592
6. I plan to be here to observe the wrap; I'll be 101+six months in Sept
2042.
Barry Merrill
years.
2. I have seen IMS APARs that indicate STCKE values are now stored in some
control blocks.
3. The TODSTAMP wrap only impacts SMF record fields that are in TOD format;
the SMFSTAMP
format has no wrap because it's date is a separate 4-byte part of the
8-byte field,
and the date contains the century bit, which won't wrap for 254
centuries.
4. TODSTAMP has microsecond resolution, while SMFSTAMP is limited to 10
milliseconds,
so TODSTAMP is (IMO) preferred in new SMF records, except for the SMFTIME
field in
the header that still needs to be SMFSTAMP format.
5. In MXG processing members, I observed these counts:
IBM SMF records Vendor SMF records Total Instances
TODSTAMPs 651 667 1318
SMFSTAMPs 147 345 592
6. I plan to be here to observe the wrap; I'll be 101+six months in Sept
2042.
Barry Merrill
John Gilmore
Jan 31, 2012, 7:58:03 PM1/31/12
to
My original point was that new programs should obtain and work only
with sixteen-byte STCKE values.
The imposed SMFSTAMP-value format must in the short term be
respected, but this requirement does not entail use of eight-byte STCK
values in programming. It is better to discard some TOD data in some
fields than not to have them available.
About Y2k windowing and the usability of similar techniques for
STCK-value windowing opinions may differ greatly. The Y2k windowing
schemes I am familiar with have mostly worked badly and required much
tinkering/adjustment, as indeed have other ad hoc Y2k remediation
schemes. (it is not much talked about, but Y2K-related maintenance
expenses are ongoing in many large IT organizations.)
What can be said with some confidence is that in the light of our Y2K
experience there will and should be little sympathy for those who do
not address the 2042 problem in a timely way.
--jg
with sixteen-byte STCKE values.
The imposed SMFSTAMP-value format must in the short term be
respected, but this requirement does not entail use of eight-byte STCK
values in programming. It is better to discard some TOD data in some
fields than not to have them available.
About Y2k windowing and the usability of similar techniques for
STCK-value windowing opinions may differ greatly. The Y2k windowing
schemes I am familiar with have mostly worked badly and required much
tinkering/adjustment, as indeed have other ad hoc Y2k remediation
schemes. (it is not much talked about, but Y2K-related maintenance
expenses are ongoing in many large IT organizations.)
What can be said with some confidence is that in the light of our Y2K
experience there will and should be little sympathy for those who do
not address the 2042 problem in a timely way.
--jg
--
John Gilmore, Ashland, MA 01721 - USA
John Gilmore, Ashland, MA 01721 - USA
Phil Smith
Jan 31, 2012, 7:59:41 PM1/31/12
to
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 known as? zGalaxy?
> 6. I plan to be here to observe the wrap; I'll be 101+six months in Sept
2042.
Ken Porowski
Jan 31, 2012, 8:50:05 PM1/31/12
to
Watson should be answering all the questions by then .
--------------------------------------------------------------------------
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"), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sen!
t from or received at this email address.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
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"), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sen!
t from or received at this email address.
--------------------------------------------------------------------------
Paul Gilmartin
Jan 31, 2012, 9:11:42 PM1/31/12
to
On Tue, 31 Jan 2012 15:48:16 -0500, Ken Porowski wrote:
>Watson should be answering all the questions by then .
>
Siri.
>Watson should be answering all the questions by then .
>
-- gil
Ken Porowski
Jan 31, 2012, 9:44:21 PM1/31/12
to
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 subsidiaries or affiliates (collectively, "CIT"), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sen!
t from or received at this email address.
--------------------------------------------------------------------------
Paul Gilmartin
--------------------------------------------------------------------------
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"), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sen!
t from or received at this email address.
--------------------------------------------------------------------------
Mike Schwab
Feb 1, 2012, 1:40:07 AM2/1/12
to
On Tue, Jan 31, 2012 at 3:03 PM, Paul Gilmartin <PaulGB...@aim.com> 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?
> On Tue, 31 Jan 2012 15:48:16 -0500, Ken Porowski wrote:
>
>>Watson should be answering all the questions by then .
>>
> Siri.
>
> -- gil
http://www.funnyordie.com/videos/2bcb35e787/cockblocked-by-siri
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Gerhard Postpischil
Feb 1, 2012, 6:43:59 AM2/1/12
to
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? <G>
> Watson should be answering all the questions by then .
Gerhard Postpischil
Bradford, VT
John Gilmore
Feb 1, 2012, 1:48:23 PM2/1/12
to
Gerhard Postpischil wrote:
| And Toronto will be a U.S. city? <G>
I was reliably informed that 'Toronto' has for some reason always been
| And Toronto will be a U.S. city? <G>
problematic; a precursor of Watson, reasoning by phonetic analogy with
'Taranto', moved it to Italy in a slightly different context.
--jg
--
John Gilmore, Ashland, MA 01721 - USA
John Gilmore, Ashland, MA 01721 - USA
Ken Porowski
Feb 1, 2012, 4:13:02 PM2/1/12
to
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"), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sen!
t from or received at this email address.
--------------------------------------------------------------------------
Gerhard Postpischil
--------------------------------------------------------------------------
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"), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sen!
t from or received at this email address.
--------------------------------------------------------------------------
contact...@gmail.com
Mar 11, 2017, 7:41:04 PM3/11/17
to
Hi,
Principles operations says bit#59 is incremented for every micro second. It also says the following
"The stepping value of TOD-clock bit position 63, if implemented, is 2^-12 microseconds, or approximately 244 picoseconds. This value is called a clock unit."
Assume I got the below value from STCKE instruction
00D23883A340D7DC0800000007140000
*
*D = b'1101' and it indicates the bits 56,57,58,59. And we know that bit 59 indicates a microsecond.
Now, how do I read x'C08' starting from bit#60? What does this value count upto?
Thanks
Murali
Principles operations says bit#59 is incremented for every micro second. It also says the following
"The stepping value of TOD-clock bit position 63, if implemented, is 2^-12 microseconds, or approximately 244 picoseconds. This value is called a clock unit."
Assume I got the below value from STCKE instruction
00D23883A340D7DC0800000007140000
*
*D = b'1101' and it indicates the bits 56,57,58,59. And we know that bit 59 indicates a microsecond.
Now, how do I read x'C08' starting from bit#60? What does this value count upto?
Thanks
Murali
contact...@gmail.com
Mar 12, 2017, 4:27:52 AM3/12/17
to
Hello Team,
I need a help in understanding ETOD further. I am working on converting ETOD to date/time formats. All documentation around this talks only about microsecond precision (i.e., bit 51 of TOD or bit 59 of ETOD). But I am trying to print even the Pico seconds.
Hhmmss.mmmuuunnnppp
Where
m - milli
u - micro
n - nano
p - pico
I didn't see enough documentation on the bits following that (i.e bits 60 to 112 of STCKE output). What does these bits signify then?
How do I translate the ETOD to the time value up to Pico seconds precision?
Can someone help me understanding the bits 60 onwards in ETOD please?
Thanks
Murali
I need a help in understanding ETOD further. I am working on converting ETOD to date/time formats. All documentation around this talks only about microsecond precision (i.e., bit 51 of TOD or bit 59 of ETOD). But I am trying to print even the Pico seconds.
Hhmmss.mmmuuunnnppp
Where
m - milli
u - micro
n - nano
p - pico
I didn't see enough documentation on the bits following that (i.e bits 60 to 112 of STCKE output). What does these bits signify then?
How do I translate the ETOD to the time value up to Pico seconds precision?
Can someone help me understanding the bits 60 onwards in ETOD please?
Thanks
Murali
Robert Wessel
Mar 13, 2017, 11:13:48 PM3/13/17
to
On Sat, 11 Mar 2017 11:41:01 -0800 (PST), contact...@gmail.com
wrote:
It's just more fractional bits to the right. You can consider the
long TOD clock one of two ways. In both cases bit 59 effectively
increments every microseconds. Simply, you can just consider it as
having an additional 68 fraction bits on the right end. IOW, if bit
59 is 1.0us, bit 60 is .5us, bit 61 is .25us, bit 63 is .125us, etc.
You can choose to truncate the last 16 bits off of that if you want to
ignore the programmable field.
While a user can set the clock to any base they want, it's usually
adjusted so that January 1, 1900 is zero.
You should read the PofO on the subject, it's explained quite
thoroughly.
wrote:
long TOD clock one of two ways. In both cases bit 59 effectively
increments every microseconds. Simply, you can just consider it as
having an additional 68 fraction bits on the right end. IOW, if bit
59 is 1.0us, bit 60 is .5us, bit 61 is .25us, bit 63 is .125us, etc.
You can choose to truncate the last 16 bits off of that if you want to
ignore the programmable field.
While a user can set the clock to any base they want, it's usually
adjusted so that January 1, 1900 is zero.
You should read the PofO on the subject, it's explained quite
thoroughly.
0 new messages