.)
Sent: Thursday, March 01, 2012 7:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
In 5189662539998554.wa.ibmmaintpg.com...@bama.ua.edu, on 02/29/2012
at 07:05 AM, Shane Ginnane ibm-m...@tpg.com.au said:
Yep, it's called TZDATA. Pity IBM hasn't gotten
David,
Perfect-hash schemes are often very useful for match-seeking. They
are not, however, usable for bound-seeking--here specifically
GLB-seeking--operations that evaluate a step function. Very few of
the search arguments--STCKE/TOD-clock values--for which a bound is
sought are even present
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom,
on 03/01/2012
at 03:01 PM, McKown, John john.mck...@healthmarkets.com said:
Curiousity, what do you mean by proper integration of Unix Services
in MVS?
E.g., all classic MVS programs able to read and write Unix files, both
On Wed, 29 Feb 2012 07:44:46 -0500, John Gilmore johnwgilmore0...@gmail.com
wrote:
Sanely organized networks, even those that do not span multiple time
zones, collect and store only UTC [GMT] STCKE values.
True.
It is then of
course possible to write trivial routines that, given a UTC
In
capd5f5oh3anxz_zc9qupe4ou8auwnto0v2anz5xx55zwrox...@mail.gmail.com,
on 02/29/2012
at 12:26 PM, John Gilmore johnwgilmore0...@gmail.com said:
Barry Merrill is of course politically entitled to his view.
Equally, he is entitled to the view that the earth is flat. The
warrant for both is
On Thu, 1 Mar 2012 05:47:38 -0600, Jan MOEYERSONS wrote:
Sanely organized networks, even those that do not span multiple time
zones, collect and store only UTC [GMT] STCKE values.
The table involved is short; it is ordered; it can be searched using
very efficient glb-seeking binary search; this
Gil,
I have made suggestions and actuals fixes, on of the Netview products, so I
would
Think IBM should be open to suggestion as long as it was justified.
The world is flat ?
Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com
On Mar 1, 2012, at 10:26 AM, Paul
In 5189662539998554.wa.ibmmaintpg.com...@bama.ua.edu, on 02/29/2012
at 07:05 AM, Shane Ginnane ibm-m...@tpg.com.au said:
Yep, it's called TZDATA. Pity IBM hasn't gotten sufficiently
organized to embrace it for z/OS Damn, I guess that places me
alongside gil/John. Thus a (nominal) triumvirate -
Of Shmuel Metz (Seymour J.)
Sent: Thursday, March 01, 2012 7:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
In 5189662539998554.wa.ibmmaintpg.com...@bama.ua.edu, on 02/29/2012
at 07:05 AM, Shane Ginnane ibm-m...@tpg.com.au said:
Yep, it's called
On 1 March 2012 16:01, McKown, John john.mck...@healthmarkets.com wrote:
What would I like? A complete GNU tool chain. Also, current versions of Perl,
python, ruby, gawk, sed, grep, bash, vim, emacs(?). Of course, I realise that
IBM cannot afford to supply these things for free. I,
, 2012 7:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
In 5189662539998554.wa.ibmmaintpg.com...@bama.ua.edu, on 02/29/2012
at 07:05 AM, Shane Ginnane ibm-m...@tpg.com.au said:
Yep, it's called TZDATA. Pity IBM hasn't gotten sufficiently
organized
and The
MEGA Life and Health Insurance Company.SM
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford
Sent: Thursday, March 01, 2012 3:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time
On Thu, 1 Mar 2012 16:08:46 -0500, Tony Harminc wrote:
On 1 March 2012 16:01, McKown, John wrote:
What would I like? A complete GNU tool chain. Also, current versions of
Perl, python, ruby, gawk, sed, grep, bash, vim, emacs(?). Of course, I
realise that IBM cannot afford to supply these
on 02/29/2012
at 12:26 PM, John Gilmore johnwgilmore0...@gmail.com said:
Barry Merrill is of course politically entitled to his view.
Equally, he is entitled to the view that the earth is flat. The
warrant for both is much the same.
http://en.wikipedia.org/wiki/The_Blue_Marble
--
Mike A
On 29/02/2012 8:44 PM, John Gilmore wrote:
The table involved is short; it is ordered; it can be searched using
very efficient glb-seeking binary search; this table grows very
slowly;
Wouldn't a perfect hash algorithm be quicker?
John Gilmore, Ashland, MA 01721 - USA
On Tue, 28 Feb 2012 19:45:11 +, Rob Scott rsc...@rocketsoftware.com wrote:
Obviously this assumes you know the UTC offset at the time of the LPAR
And that is exactly where it hurts... How does one know what the offset was at
the time the timestamp was taken? Due to daylight saving, it is
On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin paulgboul...@aim.com wrote:
Set time zone with tzset().
Call localtime() then strftime().
I am not sure this will work correctly. The gmtime(), localtime() and mktime()
always use the daylight savings situation of the current date, not of the
I cannot be the only one who finds these discussions tedious.
The archives contain more than a hundred threads very much like this
one. The same issues are discussed, more or less inadequately, over
and over again.
Sanely organized networks, even those that do not span multiple time
zones,
On Wed, 29 Feb 2012 07:44:46 -0500, John Gilmore johnwgilmore0...@gmail.com
wrote:
I cannot be the only one who finds these discussions tedious.
C'mon John, at least they tend to stray less than some (most ?) others.
...
The table involved is short; it is ordered; it can be searched using
:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
On Tue, 28 Feb 2012 09:57:44 -0800, Charles Mills wrote:
Is there any straightforward way to convert an STCK value from some
point in the fairly recent (months, not decades) past to local time for
the LPAR's locale
Jan MOEYERSONS wrote:
On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin paulgboul...@aim.com
wrote:
Set time zone with tzset().
Call localtime() then strftime().
I am not sure this will work correctly. The gmtime(), localtime() and
mktime() always use the daylight savings
On Wed, 29 Feb 2012 09:12:20 -0600, Bill Godfrey wrote:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB5A0/E.6.2
The value in the word returned by this routine is in seconds-since-1/1/1970,
but, unlike the value returned by the C library time() function and expected
by
On Wed, 29 Feb 2012 05:53:14 -0600, Jan MOEYERSONS wrote:
On Tue, 28 Feb 2012 19:45:11 +, Rob Scott wrote:
Obviously this assumes you know the UTC offset at the time of the LPAR
And that is exactly where it hurts... How does one know what the offset was at
the time the timestamp was taken?
Don Poitras wrote:
Jan MOEYERSONS wrote:
On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin paulgboul...@aim.com
wrote:
Set time zone with tzset().
Call localtime() then strftime().
I am not sure this will work correctly. The gmtime(), localtime() and
mktime() always
On Wed, 29 Feb 2012 09:47:03 -0600, Paul Gilmartin wrote:
On Wed, 29 Feb 2012 09:12:20 -0600, Bill Godfrey wrote:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB5A0/E.6.2
The value in the word returned by this routine is in seconds-since-1/1/1970,
but, unlike the value
On Wed, 29 Feb 2012 10:11:06 -0600, Bill Godfrey wrote:
On Wed, 29 Feb 2012 09:47:03 -0600, Paul Gilmartin wrote:
On Wed, 29 Feb 2012 09:12:20 -0600, Bill Godfrey wrote:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB5A0/E.6.2
The value in the word returned by this routine is
On Wed, Feb 29, 2012 at 8:00 AM, Paul Gilmartin paulgboul...@aim.comwrote:
On Wed, 29 Feb 2012 05:53:14 -0600, Jan MOEYERSONS wrote:
On Tue, 28 Feb 2012 19:45:11 +, Rob Scott wrote:
Obviously this assumes you know the UTC offset at the time of the LPAR
And that is exactly where it
FALSE:
Sanely organized networks, even those that do not span multiple time
zones, collect and store only UTC [GMT] STCKE values.
TRUE:
Truly sanely organized networks, of any description, collect and store
EITHER the UTC datetime value OR the local datetime value, and
the GMT Offset to the
Barry Merrill is of course politically entitled to his view. Equally,
he is entitled to the view that the earth is flat. The warrant for
both is much the same.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe /
On Wed, 29 Feb 2012 11:07:31 -0600, Barry Merrill wrote:
FALSE:
Sanely organized networks, even those that do not span multiple time
zones, collect and store only UTC [GMT] STCKE values.
STCKE is notionally closer to TAI than to UTC in that TAI and STCKE
are continuous timescales and UTC is
Paul Gilmartin writes:
begin extract
STCKE is notionally closer to TAI than to UTC in that TAI and STCKE
are continuous timescales and UTC is discontinous. TAI and STCKE both
embody the notion of (micro)seconds since an epoch; UTC is specified
in terms of mm dd hh mm ss.fraction with
John and Gil,
Wow you sound very similar , very impressive knowledge
Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com
On Feb 29, 2012, at 3:43 PM, John Gilmore johnwgilmore0...@gmail.com wrote:
Paul Gilmartin writes:
begin extract
STCKE is notionally
On Wed, 29 Feb 2012 15:43:02 -0500, John Gilmore wrote:
Paul Gilmartin writes:
begin extract
STCKE is notionally closer to TAI than to UTC in that TAI and STCKE
are continuous timescales and UTC is discontinous. TAI and STCKE both
embody the notion of (micro)seconds since an epoch; UTC is
On Wed, Feb 29, 2012 at 2:38 PM, Paul Gilmartin paulgboul...@aim.comwrote:
On Wed, 29 Feb 2012 15:43:02 -0500, John Gilmore wrote:
Paul Gilmartin writes:
begin extract
STCKE is notionally closer to TAI than to UTC in that TAI and STCKE
are continuous timescales and UTC is discontinous.
Paul Gilmartin wrote:
| By the way, the embolismic day in bissextile years
| is February 24, the sixth day before the kalends of March.
Yes and no. In some medieval versions of what we call the Julian
calendar---It was then called the Roman calendar---February 24th was
duplicated; there were
Not at all John my patience isn't tried learned a bunch, looked up TAI, new
acronym for me.
Thank you
Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com
On Feb 29, 2012, at 6:52 PM, John Gilmore johnwgilmore0...@gmail.com wrote:
Paul Gilmartin wrote:
| By the way,
Is there any straightforward way to convert an STCK value from some point in
the fairly recent (months, not decades) past to local time for the LPAR's
locale? By straightforward I mean without having to maintain my own table
of time changes for the historic period?
I know about CVTLDTO (and
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Charles Mills
Sent: 28 February 2012 17:58
To: IBM-MAIN@bama.ua.edu
Subject: How convert historic STCK to local time?
Is there any straightforward way to convert an STCK value from some point in
the fairly
On Tue, 28 Feb 2012 09:57:44 -0800, Charles Mills wrote:
Is there any straightforward way to convert an STCK value from some point in
the fairly recent (months, not decades) past to local time for the LPAR's
locale? By straightforward I mean without having to maintain my own table
of time changes
AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
STCKCONV and CONVTOD are both provided macro services to translate between
STCK values and various date/time formats
--
For IBM-MAIN subscribe
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Tuesday, February 28, 2012 10:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
On Tue, 28 Feb 2012 09:57:44 -0800, Charles Mills wrote
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Tuesday, February 28, 2012 10:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
Call localtime()
Are you *sure*? In my experiments on both
@bama.ua.edu] On Behalf Of
Charles Mills
Sent: 28 February 2012 18:39
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
If I had a TOD clock value from roughly six months ago, how would I use
STCKCONV to convert it to local time for the LPAR's locale?
Charles
-Original
Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Rob Scott
Sent: Tuesday, February 28, 2012 11:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
Something like :
LG GR0,CURR_STCK UTC
ALG GR0,LPAR_STCK_OFFSET
-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills
Sent: Tuesday, February 28, 2012 2:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
this assumes you know the UTC offset at the time of the LPAR
That's
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills
Sent: Tuesday, February 28, 2012 2:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
this assumes you know the UTC offset at the time of the LPAR
On Tue, 28 Feb 2012 20:11:09 +, Rob Scott wrote:
If you are lucky enough to be in control of the data collection, then you
could save the CVTLDTO value in the same control block or record as the STCK
value so that you can accurately re-construct local time at a later date.
And the data may
-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
On Tue, 28 Feb 2012 20:11:09 +, Rob Scott wrote:
If you are lucky enough to be in control of the data
collection, then you could save the CVTLDTO value in the same
control block or record as the STCK value so
.
Thanks,
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Tuesday, February 28, 2012 10:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How convert historic STCK to local time?
On Tue, 28 Feb 2012 09:57:44 -0800
49 matches
Mail list logo
