Getting into the realms of off topic:
>>That was also when the maximum name length was increased to
>>accommodate
>>llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch.com.
>???
Longest place name in the UK. Despite what the website says it
used to be that the official name was Llanfairpwl
On Nov 5, 2009, at 22:51, Glenn Knickerbocker wrote:
On Thu, 5 Nov 2009 22:14:43 -0700, Paul Gilmartin wrote:
On 11/05/09 11:17, Rob van der Heij wrote:
was a valid test in the past (until 3COM got some arms bent for the
domain).
I was unaware of such arm-bending.
From RFC 1123:
(titled:
On Thu, 5 Nov 2009 22:14:43 -0700, Paul Gilmartin wrote:
>On 11/05/09 11:17, Rob van der Heij wrote:
>> was a valid test in the past (until 3COM got some arms bent for the
>> domain).
>I was unaware of such arm-bending.
From RFC 1123:
>2.1 Host Names and Numbers
>
> The syntax of a legal I
On Nov 5, 2009, at 08:33, John P. Hartmann wrote:
Bob, a leading zero in an IP address means the the component is octal.
Are you sure you don't want the letter O rather than the digit 0?
Not that I have the faintest idea what us.pool.ntp.org is all about.
I use one of the nist servers (time-a.n
There must be a new one to handle the new (Thai-excepted) non-latin character
sets.
i
-- Original Message --
Received: 08:13 PM COT, 11/05/2009
From: Paul Gilmartin
To: cms-pipeli...@listserv.meduniwien.ac.at
Subject: Re: Using PIPE to obtain the GMT time from an ntp server?
> On 11/05/
On 11/05/09 11:17, Rob van der Heij wrote:
On Thu, Nov 5, 2009 at 6:54 PM, Jack Woehr wrote:
But it's on VMTOOLS and that's part of the distrib, right, not something I
can download and look at the Rexx?
It has nothing to do with the built-in stage, so would not be helpful
to see the cause.
Bob Cronin wrote:
I need two separate pipe invocations for that?
Well, I meant you put it all in the pipeline and pipe the result as the
argument
to the next, however that works in code.
I don't *think* that's the way it's *supposed* to work for a tcpclient
stage but
you found a nice bugle
Bob Cronin wrote:
Hm, the first two servers I tried upon manually issuing the hostbyname
refused to accept the connection.
Yes, I used telnet to test the address you gave in your first posting,
and I had
the same result!
--
Jack J. Woehr# «'I know what "it" means well enough
Hm, the first two servers I tried upon manually issuing the hostbyname
refused to accept the connection. Maybe I'll stick with time-a.nist.gov. I
wish someone ran an internal timeserver that supported daytime. Haven't
found one yet from amongst the likely candidates.
--
bc
On Thu, Nov 5, 2009 at 4
I need two separate pipe invocations for that?
--
bc
On Thu, Nov 5, 2009 at 3:24 PM, Jack Woehr wrote:
> Bob Cronin wrote:
>
>> Hm, so trying to be a good citizen, I use, e.g., 0.us.pool.ntp.org on
>> that
>> tcpclient invocation and get this somewhat baffling response:
>>
>>
> Anyway, the quick
Bob Cronin wrote:
Hm, so trying to be a good citizen, I use, e.g., 0.us.pool.ntp.org on that
tcpclient invocation and get this somewhat baffling response:
Anyway, the quick fix for what you are doing is use a
HOSTBYNAME Resolves a domain or host name into an IP (internet
protocol) addr
Jack Woehr wrote:
Ian S. Worthington wrote:
A very quick look suggests that ip2socka might be the culprit
ip2socka *only* interprets numbers. a decision is made earlier to call
ip2socka if it's indeed called from tcpclient
My host is down until later today. Anybody looking at TCPCLIE R
Ian S. Worthington wrote:
A very quick look suggests that ip2socka might be the culprit
ip2socka *only* interprets numbers. a decision is made earlier to call
ip2socka if it's indeed called from tcpclient
--
Jack J. Woehr# «'I know what "it" means well enough, when I find
http
Many thanks Mike and Ian. Exactly the sort of info I was looking for (what
seems so long ago now ;-).
--
bc
On Wed, Nov 4, 2009 at 6:13 PM, Ian S. Worthington
wrote:
> You should probably be using the server pool for this kind of thing rather
> than an individual server.
>
> See http://www.pool.n
You should probably be using the server pool for this kind of thing rather
than an individual server.
See http://www.pool.ntp.org/zone/us for more information
i
-- Original Message --
Received: 06:09 PM COT, 11/04/2009
From: Michael Harding
To: cms-pipeli...@listserv.meduniwien.ac.at
Su
Referring to http://tf.nist.gov/timefreq/service/its.htm
For your basic needs:
Pipe literal |tcpclient nist1.symmetricom.com 13 oneresponse|xlate a2e|
cons
55139 09-11-04 21:09:38 00 0 0 0.0 UTC(NIST) *
Ready; T=0.01/0.01 13:09:37
That's a left-coast server. Depending on where you are you mi
On Nov 3, 2009, at 19:54, Leslie Turriff wrote:
Of course! It needs to be done long before any OS gets IPLed,
since the
(real) TOD clock is set during the POR process.
Unless you've paid for STP, which steers the TOD clock continuously,
by infinitesimal increments.
-- gil
On Tuesday 03 November 2009 20:36:37 Paul Gilmartin wrote:
> On 11/03/09 19:25, Leslie Turriff wrote:
> > On Tuesday 03 November 2009 20:09:49 Paul Gilmartin wrote:
> >> On 11/03/09 17:42, Leslie Turriff wrote:
> >>> Philosophical question: Has anyone posted a requirement to SHARE
> >>> or som
On 11/03/09 19:25, Leslie Turriff wrote:
On Tuesday 03 November 2009 20:09:49 Paul Gilmartin wrote:
On 11/03/09 17:42, Leslie Turriff wrote:
Philosophical question: Has anyone posted a requirement to SHARE or
some such to get an interface to an NTP source into the firmware so that
the TOD
On Tuesday 03 November 2009 17:40:35 Rob van der Heij wrote:
> On Tue, Nov 3, 2009 at 4:14 PM, Paul Gilmartin wrote:
> >> This is cheating. Sure, if you assume the operating system has the
> >> right time, you just ask there...
> >
> > So it's cheating to ask your own OS, but not cheating to ask
>
On Tuesday 03 November 2009 20:09:49 Paul Gilmartin wrote:
> On 11/03/09 17:42, Leslie Turriff wrote:
> > Philosophical question: Has anyone posted a requirement to SHARE or
> > some such to get an interface to an NTP source into the firmware so that
> > the TOD clock can be synchronized to a
On Tue, Nov 3, 2009 at 4:14 PM, Paul Gilmartin wrote:
>> This is cheating. Sure, if you assume the operating system has the
>> right time, you just ask there...
>>
> So it's cheating to ask your own OS, but not cheating to ask
> a remote OS? What if your system lacks network connection?
You jus
On 11/03/09 17:42, Leslie Turriff wrote:
Philosophical question: Has anyone posted a requirement to SHARE or some
such to get an interface to an NTP source into the firmware so that the TOD
clock can be synchronized to a reliable source (other than the operator's
wristwatch or the computer
On Tue, Nov 3, 2009 at 4:18 PM, Paul Gilmartin wrote:
> Will VM _ever_ learn to use ETR, STP, whatever? Last I heard it
> couldn't,
> much less being leap second aware. Causes us problems with z/OS guests.
Sorry, you must be listening to the wrong folks. z/VM will enjoy the
steering of the TOD
On Nov 3, 2009, at 09:47, Bob Cronin wrote:
All well and good, but useless if the GMT time is wrong (which it
is on most
of our VM systems, at least as compared to GMT returned from one of
the many
reliable NTP servers out there). All I want to be able to do is to
talk to
one of those servers an
All well and good, but useless if the GMT time is wrong (which it is on most
of our VM systems, at least as compared to GMT returned from one of the many
reliable NTP servers out there). All I want to be able to do is to talk to
one of those servers and get an answer as to what time it thinks it is
Yes indeed, but it isn't far away: remember EXEC2?
GMTTIME EXEC A1 V 130 Trunc=130
>
!...+1+2+3+
* * * Top of File * * *
&TRACE
CP Q T
CP Q TIMEZONE
&TYPE GMT Date and time: &DATE &TIME
* * * End of File * * *
TIME IS 16:32:01 CET TUESDAY 2009-11-03
CONNECT=
On Nov 3, 2009, at 07:54, Bob Cronin wrote:
Our VM clocks are so far off that I wouldn't even care if the
answer I got
from the ntp server was a few seconds off because of latency...
Will VM _ever_ learn to use ETR, STP, whatever? Last I heard it
couldn't,
much less being leap second aware.
On Nov 3, 2009, at 00:21, Rob van der Heij wrote:
On Mon, Nov 2, 2009 at 10:50 PM, Paul Gilmartin
wrote:
Is there a stage that talks to OpenEdition CMS? (I have _no_
experience with OpenEdition CMS.) If so, all that's necessary
is to capture the output of "TZ=GMT0 date".
(In TSO it's easy
Our VM clocks are so far off that I wouldn't even care if the answer I got
from the ntp server was a few seconds off because of latency...
--
bc
On Tue, Nov 3, 2009 at 2:21 AM, Rob van der Heij wrote:
> On Mon, Nov 2, 2009 at 10:50 PM, Paul Gilmartin
> wrote:
>
> > Is there a stage that talks t
On Mon, Nov 2, 2009 at 10:50 PM, Paul Gilmartin wrote:
> Is there a stage that talks to OpenEdition CMS? (I have _no_
> experience with OpenEdition CMS.) If so, all that's necessary
> is to capture the output of "TZ=GMT0 date".
>
> (In TSO it's easy enough with "address SYSCALL".)
This is chea
On Mon, 2 Nov 2009 16:06:03 -0500 Bob Cronin said:
>Does anyone have PIPE code that can talk to a remote ntp timeserver and
>retrieve the current GMT time?
With the caveat that UICVM no longer exists
http://listserv.uark.edu/scripts/wa.exe?A2=ind9804&L=ibmvm&T=0&P=1901
>--
>bc
On 11/02/09 14:06, Bob Cronin wrote:
Does anyone have PIPE code that can talk to a remote ntp timeserver and
retrieve the current GMT time?
Is there a stage that talks to OpenEdition CMS? (I have _no_
experience with OpenEdition CMS.) If so, all that's necessary
is to capture the output of "T
Does anyone have PIPE code that can talk to a remote ntp timeserver and
retrieve the current GMT time?
--
bc
34 matches
Mail list logo
