From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, May 15, 2021 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STIMERM LT value
On Sat, 15 May 2021 03:51:45 -0700, Ed Jaffe
On Sat, 15 May 2021 03:51:45 -0700, Ed Jaffe wrote:
>On 5/14/2021 9:53 PM, Alan Altmark wrote:
>>
>> Then if the client wants to reduce the price by redlining items, that's on
>> them, but I think IBM or the BP should be bringing a full function proposal.
>
>Car radios used to be extra. Now they
On 5/14/2021 9:53 PM, Alan Altmark wrote:
Help me with this, Ed. Did you receive a proposal that didn't include STP? Or
at least offer it as an option? If it wasn't offered, that bothers me. IMO,
all proposals should include cryptos (where not prohibited by law), a pair of
copper OSAs,
nframe Discussion List On
> Behalf Of Alan Altmark
> Sent: Friday, May 14, 2021 9:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STIMERM LT value
>
> On Fri, 14 May 2021 05:28:52 -0700, Ed Jaffe
> wrote:
> >Reasonable people can disagree about what the word "p
On 5/14/2021 9:53 PM, Alan Altmark wrote:
Help me with this, Ed. Did you receive a proposal that didn't include STP? Or
at least offer it as an option? If it wasn't offered, that bothers me. IMO,
all proposals should include cryptos (where not prohibited by law), a pair of
copper OSAs,
On Fri, 14 May 2021 05:28:52 -0700, Ed Jaffe
wrote:
>Reasonable people can disagree about what the word "pricey" means, but
>no one can defend the indefensible.
>
>Every Intel-based Linux, Windows or Mac, at every hardware price-point,
>can synchronize its clock with an external NTP sever in
On 5/13/2021 10:19 PM, Alan Altmark wrote:
Ed, I won't argue the point of "Why isn't in a standard feature?" (I wish it was, too),
but I will take issue with "pricey". I was surprised at how inexpensive it actually is,
particularly when I look at what it does.
Reasonable people can
On Tue, 11 May 2021 03:25:35 -0700, Ed Jaffe
wrote:
>We experienced significant clock drift on our z13s. (I can't understand
>why IBM makes STP optional and pricey. All Z machines should be able to
>synchronize to NIST.)
Ed, I won't argue the point of "Why isn't in a standard feature?" (I wish
On Thu, 13 May 2021 17:51:47 -0400, George Kozakos wrote:
>> How does STIMER behave when the interval spans a DST or leap second
>> boundary? Is this documented?
>
>STIMER does not need to know the interval spans a DST or leap second
>boundary. When a DST or leap second change occurs an
> How does STIMER behave when the interval spans a DST or leap second
> boundary? Is this documented?
STIMER does not need to know the interval spans a DST or leap second
boundary. When a DST or leap second change occurs an adjustment is
made to existing TQEs.
George Kozakos, z/OS Software
nt: Thursday, May 13, 2021 1:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STIMERM LT value
>
> > > It is also possible to set a user specified LPAR offset via PTFF-STOU
> (E)
> > > without IPLing but you need to be aware you are jumping the LPAR TOD
> on
> > It is also possible to set a user specified LPAR offset via PTFF-STOU
(E)
> > without IPLing but you need to be aware you are jumping the LPAR TOD on
a
> > running system.
>
> PTFF-STOU(E)? Is this something I'm supposed to recognize? What are you
> trying to tell me?
See the PERFORM TIMING
On Tue, 11 May 2021 03:25:35 -0700, Ed Jaffe wrote:
>
>We experienced significant clock drift on our z13s. (I can't understand
>why IBM makes STP optional and pricey. All Z machines should be able to
>synchronize to NIST.)
>
>This discrepancy wreaked havoc for our folks trying to use the
On 5/12/2021 3:59 PM, George Kozakos wrote:
Are you IPLing to pick up the new TIMEZONE or are you using SET CLOCK
as SET TIMEZONE only accepts hours and minutes?
We IPL every Sunday morning to pick up the previous week's IBM service.
We also pick up TIMEZONE changes at the same time.
You
On 5/13/2021 5:48 AM, Paul Gilmartin wrote:
On Wed, 12 May 2021 18:59:53 -0400, George Kozakos wrote:
...
Without STP, you can access an ETS via an NTP server on the HMC to make
sure the HMC clock is accurate, and just before POR set the SE clock to
the HMC clock via "Use Console Time" on
On Wed, 12 May 2021 18:59:53 -0400, George Kozakos wrote:
>...
>Without STP, you can access an ETS via an NTP server on the HMC to make
>sure the HMC clock is accurate, and just before POR set the SE clock to
>the HMC clock via "Use Console Time" on the SE Date/Time panel (accessed
>via the
Support Element
Date/Time) to ensure the CPC TOD is set to the correct time at POR.
Regards,
George Kozakos, z/OS Software Service
IBM Mainframe Discussion List wrote on
11/05/2021 06:25:35 AM:
> From: Ed Jaffe
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/05/2021 06:25 AM
> Subj
On Tue, 11 May 2021 08:54:05 +1000, Attila Fogarasi wrote:
>Z/os has to handle arbitrary TIMEZONE values -- and does it well. Keep in
>mind that there are dozens of world locations that have non-hour timezone
>
It does it poorly. Of the "dozens of world locations" any z/OS system
handles only
On 5/11/2021 1:40 AM, Steve Austin wrote:
And apparently, "someone pointed out that the hardware clock was 1 minute
out, so a minute was added". I don't know, but my guess is that the person
setting up the Jenkins builds noticed the clock was wrong.
We experienced significant clock drift on
Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Monday, May 10, 2021 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STIMERM LT value
(I guess Peter R. overlooked that you appear to be operating near the Prime
Meridi
On Mon, 10 May 2021 20:00:39 -0500, Mike Schwab wrote:
>Since IBM and Linux / Unix handle Leap Seconds differently, is this
>done so MVS is ahead of Linux, because if you are behind you get
>rejected?
>
z/OS handles this pretty well by pausing during a leap second.
Linux/UNIX systems use NTP and
Since IBM and Linux / Unix handle Leap Seconds differently, is this
done so MVS is ahead of Linux, because if you are behind you get
rejected?
On Mon, May 10, 2021 at 5:54 PM Attila Fogarasi wrote:
>
> Z/os has to handle arbitrary TIMEZONE values -- and does it well. Keep in
> mind that there
Z/os has to handle arbitrary TIMEZONE values -- and does it well. Keep in
mind that there are dozens of world locations that have non-hour timezone
offsets (typically 30 min and 15 min). There are even locations which have
Daylight Saving Time 30 min ahead of standard time instead of the usual 1
(I guess Peter R. overlooked that you appear to be operating
near the Prime Meridian.)
On Mon, 10 May 2021 09:52:16 +0100, Steve Austin wrote:
>I've just found out that PARMLIB(CLOCKxx) here specifies;
>
> TIMEZONE E.01.01.00
>
Ouch! Does that mean that SYSLOG, etc. timestamps are a minute
[mailto:steve.aus...@macro4.com]
Sent: Monday, May 10, 2021 9:22 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: STIMERM LT value
I've run the test twice more specifying a time of 9 o'clock, the 1st with
a STIMERM and an LT=value and the 2nd a GMT=value. Below are the results
and an extract
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Sunday, May 9, 2021 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STIMERM LT value
Perhaps the OP should try using GMT= instead of LT=, to see just how
things work without the time zone offset
Perhaps the OP should try using GMT= instead of LT=, to see just how
things work without the time zone offset coming into play.
Is it still off by a minute when using GMT= ?
Peter Relson
z/OS Core Technology Design
--
For
The code shown will result in a timer pop at 11:00:00 local time.
As to when the code will get control to issue the STCKE, that is a
question of system dispatching and priorities.
>From a dump, I think you will be able to see the external interrupt clock
comparator timer pop, at whatever
>From IPCS cbformat cvt structure(cvt)
LSO..
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Friday, May 7, 2021 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STIMERM LT value
On Fri
On Fri, 7 May 2021 11:37:40 +0100, Steve Austin wrote:
>I ran the code below on a Z15 and a z/PDT and got the values shown. Both
>are running summertime accounting the 09. But the result is a minute awry
>of what I was hoping for. What STIMERM LT value would I need to specify for
>11 o’clock?
>
30 matches
Mail list logo
