In ,
on 03/01/2012
at 03:01 PM, "McKown, John" 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
individually and in concatenations, all Unix utilities able to read
and write classic MVS
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
e Company.SM
>
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
>> Sent: Thursday, March 01, 2012 7:18 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: How conve
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 02/29/2012
> at 12:26 PM, John Gilmore 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 Schwab, Springfield
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 th
the brand name for products underwritten
> and issued by the insurance subsidiaries of HealthMarkets,
> Inc. -The Chesapeake Life Insurance Company(r), Mid-West
> National Life Insurance Company of TennesseeSM and The MEGA
> Life and Health Insurance Company.SM
> >
> >
&
gt;> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
>> Sent: Thursday, March 01, 2012 7:18 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: How convert "historic"
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 things for free. I, personally, cannot
> attempt to "po
List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf 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>,
In <5189662539998554.wa.ibmmaintpg.com...@bama.ua.edu>, on 02/29/2012
at 07:05 AM, Shane Ginnane 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 - perchance to
>
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 Gi
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 sea
In
,
on 02/29/2012
at 12:26 PM, John Gilmore 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.
What are you smoking?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
On Wed, 29 Feb 2012 07:44:46 -0500, John Gilmore
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 offset,
But I think that is
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 wrote:
> Paul Gilmartin wrote:
>
> | By the way, the embolismic day in b
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 tw
On Wed, Feb 29, 2012 at 2:38 PM, Paul Gilmartin wrote:
> On Wed, 29 Feb 2012 15:43:02 -0500, John Gilmore wrote:
>
> >Paul Gilmartin writes:
> >
> >
> >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
> >e
On Wed, 29 Feb 2012 15:43:02 -0500, John Gilmore wrote:
>Paul Gilmartin writes:
>
>
>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
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 wrote:
> Paul Gilmartin writes:
>
>
> STCKE is notionally closer to TAI than to UTC in that TAI and
Paul Gilmartin writes:
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 minutes varying in
l
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
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 / s
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 tim
On Wed, Feb 29, 2012 at 8:00 AM, Paul Gilmartin wrote:
> 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...
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
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 val
Don Poitras wrote:
>
> Jan MOEYERSONS wrote:
> >
> > On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin
> > wrote:
> >
> > >Set time zone with tzset().
> > >
> > >Call localtime() then strftime().
> > >
> >
> > I am not sure this will work correctly. The gmtime(), localtime() and
> > mktime() a
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
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 lo
Jan MOEYERSONS wrote:
>
> On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin
> 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
.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:
>
>>Is there any straightforward way to c
On Wed, 29 Feb 2012 07:44:46 -0500, John Gilmore
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
>very efficient glb-seeking
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, coll
On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin 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 date
input to t
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? Due to daylight saving, it is far from
obvious to de
ues.
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 0
2:36 PM
> To: IBM-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 t
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
he
MEGA Life and Health Insurance Company.SM
> -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&quo
pany.SM
> -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?
>
age-
From: IBM 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
@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
.
Charles
-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
ot;knows"
it's local time and localtime() "knows" it's UTC?
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 conver
10:12 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
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 ch
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
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 CVTL
49 matches
Mail list logo
