On Wed, 21 May 2008 19:30:10 -0400, Alan Altmark <[EMAIL PROTECTED]
>
wrote:
>On Wednesday, 05/21/2008 at 07:25 EDT, dave <[EMAIL PROTECTED]>
>wrote:
>
>> To recap:
>> 1) VM (actually, CP) does not participate in the new SNT,
>> once CP has it's hardware TOD clock set from either the HMC
>> or the
The Linux ETR support only applies to Linux running in an LPAR. Getting
this to work for Linuxrunning in virtual machines will require VM to
accept and virtualize the new ETR signals.
Rick Barlow
Sr. z/VM Systems Programmer
Nationwide Services Co., Technolog
On Wednesday, 05/21/2008 at 07:25 EDT, dave <[EMAIL PROTECTED]>
wrote:
> To recap:
> 1) VM (actually, CP) does not participate in the new SNT,
> once CP has it's hardware TOD clock set from either the HMC
> or the Operator, that's it, no changes to the h/w TOD clock.
Disagree. See my previous p
and have a good one.
DJ
- Original Message Follows -
From: Alan Altmark <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: z/VM, NTP, and the z/10.
Date: Wed, 21 May 2008 19:08:05 -0400
> On Wednesday, 05/21/2008 at 02:43 EDT, dave
> <[EMAIL PROTECTED]> wro
R; <>< wrote:
>It's not that it doesn't work, it's just that we found the cost of
changing
>from the Linux norm to be greater than the advantage.
Exactly. There's enough other different areas that generate enough
quizzical looks. Plus the unix security baseline here says it has to be
run and
On Wednesday, 05/21/2008 at 02:43 EDT, dave <[EMAIL PROTECTED]>
wrote:
> My question is: what
> happens if z/VM is running on one of those LPARs and PR/SM,
> under the covers, keeps updating z/VM's hardware TOD clock?
As CP perceives time, nothing happens. The clock keeps on ticking. But
to th
Hi, Mike, ...
Two things seem to have gotten run together in my post.
I meant to say that running the NTP server on all guests
is better in terms of impact to the VM host than running a
poorly scheduled MULTIPLICITY of 'ntpdate' jobs nightly.
At my shop, we introduced an arbitrary staggering of t
On Wed, May 21, 2008 at 11:08 PM, Marcy Cortes
<[EMAIL PROTECTED]> wrote:
> We've been running NTP for every with no ill effects. Our
> authentication product requires it be there (to active directory so
> presumably Kerberos is the reason).
The requirements of Kerberos are moderate and require
We've been running NTP for every with no ill effects. Our
authentication product requires it be there (to active directory so
presumably Kerberos is the reason).
Now.. Funny this topic should come up. I was about to ask about this
which came out the SLES 10 SP2 Release notes:
http://www.novell.
On Wed, May 21, 2008 at 8:53 PM, Richard Troth <[EMAIL PROTECTED]> wrote:
> The spiffy thing about time on System z is that the clock is incredibly
> stable. (Ticks at the right rate, though may be off by several minutes.
> It's always off by the same "several minutes" to great precision.) If we
On Wednesday, 05/21/2008 at 12:45 EDT, Dave Jones
<[EMAIL PROTECTED]> wrote:
> A client has just installed a z10 system, with the STP server and NTP
client
> support enabled. In one LPAR there is z/OS 1.9 running and exploiting an
> external time reference to keep it's LPAR time accurate.
With S
The overhead isn't too much. We have a script in /etc/cron.daily that run
s
the ntpd program once and goes away. If I was concerned about the overhea
d,
I would do this at IPL and once a week since we don't drift more than a
second every year, but our HMC clock is off by 3 seconds. I got the scrip
Now I'm confused. You write:
> Running the NTP server is a whole lot better than even a daily
'ntpdate' via CRON.
and
> The spiffy thing about time on System z is that the clock is
incredibly stable.
So which is it?
Both are true - the key problem is that if the operator is off when he
Rick,
Now I'm confused. You write:
> Running the NTP server is a whole lot better than even a daily 'ntpdate'
via CRON.
and
> The spiffy thing about time on System z is that the clock is incredibly
stable.
So which is it?
We wrote about having one server running the full xntpd to a reliable
> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:[EMAIL PROTECTED] On Behalf Of dave
> Sent: Wednesday, May 21, 2008 12:42 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: z/VM, NTP, and the z/10.
>
> Thanks, Tom, I appreciate it. However, I wo
dware TOD clock?
>
> Or am I completely missing the point here about what STP and
> NTP client features are supposed to provide?
>
> DJ
>
> - Original Message Follows -----
> From: Thomas Kern <[EMAIL PROTECTED]>
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: z/VM,
/VM's hardware TOD clock?
Or am I completely missing the point here about what STP and
NTP client features are supposed to provide?
DJ
- Original Message Follows -
From: Thomas Kern <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: z/VM, NTP, and the z/10.
Date:
I don't think that IBM has announced the ability for z/VM to update its
clock on the fly with input from an STP/NTP service. SLES10, however, can
use an external NTP source to update its own clock (separate from the z/V
M
supervisor). I do this because our hobbit server will complain (softly bu
t
A client has just installed a z10 system, with the STP server and NTP cli
ent
support enabled. In one LPAR there is z/OS 1.9 running and exploiting an
external time reference to keep it's LPAR time accurate. With the new z/1
0
STP and NTP client functions available, can the time in the z/VM LPAR al
19 matches
Mail list logo
