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
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
Thanks, Tom, I appreciate it. However, I would prefer not to
have to run NTP clients in each of the Linux images due to
the overhead that can produce.
I think the point of confusion here is, at least to me, that
the z10 technical overview document seems to imply that STP
will be used to
To your first paragraph, Dave, actually, umm, no.
The overhead is really small for [X]NTPD on Linux.
I agree that NTP in each Linux is silly.
But the evidence suggests that NTPD is the best behaved, smallest footprint,
and all decency of the many daemons possessing virtual Linuxen. In my shop,
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
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
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
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 STP,
Is there any way to dynamically turn specific devices included in a
Devices_Notaccepted statement in the SYSTEM CONFIG file into accepted
and usable devices in z/VM 5.2? I know that I can make them Sensed via
the SET RDEVICE command; however, that looks to be a documented waste of
time.
Richard,
See HELP CPSET DEVICES.
Mark L. Wheeler
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel: (651) 733-4355, Fax: (651) 736-7689
mlwheeler at mmm.com
--
I have this theory that if one person can go out of their way to show
compassion then it will start a chain reaction of
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
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:
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
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 the
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 I
As usual, the group comes through again; many thanks to all
who have posted, it helped a lot.
Yes, the problem the client is concerned about is
implementing a security scheme across LPARs (and across CECs
as well) that requires accurate time be kept. Not
microsecond accurate, but more accurate
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 posts.
On Thu, 8 May 2008, Michael Coffin wrote:
Thanks Richard and Mary Ellen, I'll give NFS a look.
Unfortunately, my client considers NFS an unsafe technology
...
NFS is unsafe in a similar sense to how UDP is unreliable.
Context! Be sure they keep the context! NFS was designed from
a point
Cross-posted to z/VM list.
I want to thank Rob for pointing out the new STRUCTURE capabilities in
the latest runtime version of Pipelines. His presentation shows enough
to get me started on more intensive processing of z/VM's accounting data.
To add something to the community, here is my
19 matches
Mail list logo
