If your TIMEZONE_BOUNDRYs are incorrect, you will need to perform Q TIMEZONE to
see which way you want to change the clock.
q timezone
Zone Direction Offset Status
UTC 00.00.00 Inactive
GMT 00.00.00 Inactive
EDT West 04.00.00 Active
EST West
We used the SET TIMEZONE command to set the desired timezone as during
the upgrade to 5.4 the TIMEZONE_BOUNDARY statements were not set to the
desired TZ. The boundary statements have been corrected but I am
wondering if there is some way to have the system config file re-read to
put the corrected
The TIMEZONE_BOUNDARY statements are only read during IPL, there is no
automatic timezone change in VM, you need to issue SET TIMEZONE at the right
time, or IPL.
2009/10/13 Jerry Whitteridge jerry.whitteri...@safeway.com
We used the SET TIMEZONE command to set the desired timezone as during
Thanks Kris - that confirms what I thought. We will use the SET TIMEZONE
and have an IPL scheduled before the spring change.
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens
Sent: Tuesday, October 13
We used the SET TIMEZONE command to set the desired timezone as during
the upgrade to 5.4 the TIMEZONE_BOUNDARY statements were not set to the
desired TZ. The boundary statements have been corrected but I am
wondering if there is some way to have the system config file re-read to
put the corrected
Ah - so even if I had had the boundaries correct I would have had to use
SET TIMEZONE -
Thanks
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of John Franciscovich
Sent: Tuesday, October 13, 2009 1:45 PM
To: IBMVM
On Tuesday, 10/13/2009 at 01:44 EDT, Jerry Whitteridge
jerry.whitteri...@safeway.com wrote:
We used the SET TIMEZONE command to set the desired timezone as during
the
upgrade to 5.4 the TIMEZONE_BOUNDARY statements were not set to the
desired
TZ. The boundary statements have been
While waiting for Server Time Protocol from Santa,
investigate the DEFINE TIMEZONE command.
In general, CP reads SYSTEM CONFIG only at IPL.
TIMEZONE statements, CPOWNED lists, etc., are
processed only at IPL. Generally, for dynamic
changes, there are separate commands.
Always remember
We are running z/VM 5.2.0 (0602) on a z9BC.
The laptop that controls the z9BC is 13 seconds off from our network
time.
We have tried to change the time by changing TIMEZONE in the SYSTEM
CONFIG file.
We can change from PST to PDT. That worked okay.
When we change from PDT to PST
Changing the TIMEZONE in the system config only comes into play at IPL
time. System looks at the dates specified and used them to determine the
timezone to use. Check the dates if you are IPLing and not seeing a
change.
If you want to change what is currently being used, use the SET TIMEZONE
PDT
Can you post your before and after changes.
Larry Davis
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Daniel Allen
Sent: Tuesday, November 04, 2008 3:58 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Question about TIMEZONE
We
Sent: November 4, 2008 15:58
To: IBMVM@LISTSERV.UARK.EDU
Subject: Question about TIMEZONE
We are running z/VM 5.2.0 (0602) on a z9BC.
The laptop that controls the z9BC is 13 seconds off from our network
time.
We have tried to change the time by changing TIMEZONE in the SYSTEM
CONFIG file
We are on the US east coast and use EDT/EST for all out VM systems.
I have always lived and worked in the same time zone that the systems have
had.
Are there any strange things to watch out for as far as support is
concerned if we have system that runs with GMT as the time zone?
Thanks.
Not really. We have systems located in several timezones that run with
the timezone set to GMT. It helps when trying to correlate events at the
different centers. And it means never having to jump through hoops for
daylight savings time. You do have to get used to seeing timestamps that
do
When you SENDFILE a CMS file to another VM system, the timestamp of the file
is converted to GMT time, at the receiving system the local timezone offset
is used to calculate the local time that is used by the CMS file system.
So, if one system hasn't the GMT offsets coded as expected
by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
03/09/2007 05:56 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: TIMEZONE
Do ix=2007 to 2042/* What years do we want to cover? */
If ix=2042
On 3/9/07, Mike Walter [EMAIL PROTECTED] wrote:
... and IBM has better things to work on than something 35 years from now,
...
That's what everybody was saying back in 1965 about the y2k problem. :-)
Jeff Henry wrote:
On 3/9/07, *Mike Walter* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
... and IBM has better things to work on than something 35 years
from now, ...
That's what everybody was saying back in 1965 about the y2k problem. :-)
And because they said that, them
Back in the '70s I was part of a group that spec'ed out a replacement mainframe.
$1 million dollars for each MB of ram. That was when a million was a lot of
money.
Programmers cost about $14,000 a year.
Got two bits unused in your data structure? Make them flag bits.
And, of course, the
Back then we used 1 a character year, 0-9 was 1950-1959, A-J was 1960-1969 and K-T was 1970-1979. If
you want to know why look at the punch card code. 0-9 was a single punch. A-J was a + (12 punch)
with a 0-9. K-T was a - (11 punch) with a 0-9. We knew that this would break in 1980 but we
Stephen Frazier wrote:
Back then we used 1 a character year, 0-9 was 1950-1959, A-J was 1960-1969 and K-T was 1970-1979. If
you want to know why look at the punch card code. 0-9 was a single punch. A-J was a + (12 punch)
with a 0-9. K-T was a - (11 punch) with a 0-9. We knew that this would
Timezone_boundary on 2007-03-11 at 02:00:00 to EDT
Timezone_boundary on 2007-11-04 at 02:00:00 to EST
Timezone_boundary on 2008-03-09 at 02:00:00 to EDT
Timezone_boundary
Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Tony Thigpen
Sent: Thursday, March 08, 2007 11:50 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: TIMEZONE
Can somebody cut-n-paste their SYSTEM CONFIG USA Timezone_boundary
statements for the next few years. I thought I had updated it, but when
I
Thanks.
Tony Thigpen
-Original Message -
From: Anne Crabtree
Sent: 03/08/2007 11:53 AM
Timezone_boundary on 2007-03-11 at 02:00:00 to EDT
Timezone_boundary on 2007-11-04 at 02:00:00 to EST
. Craig
Sent: Thursday, March 08, 2007 12:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: TIMEZONE
On Thu, Mar 08, 2007 at 11:50:06AM -0500, Tony Thigpen wrote:
Can somebody cut-n-paste their SYSTEM CONFIG USA Timezone_boundary
statements for the next few years. I thought I had updated
...system may come up in GMT.
No, not may -- it absolutely WILL come up in GMT.
:blush on
Two weeks ago it took about 2 minutes to realize what *I* had done .. once
I stopped blaming the operators.
:blush off
Now. about future timezone dates... see the EXEC below. It produces a set
You get my vote.
Not that you need it, your Poohbah-ness, sir.
Jon
snip
Once so elected I will issue a Grande Pooh-Bah Declaration that if it is wise
to save daylight in the summer, it's even wiser to save it in winter - so we'll
stay on Daylight Savings Time which will henceforth
to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: TIMEZONE
You get my vote.
Not that you need it, your Poohbah-ness, sir.
Jon
snip
Once so elected I will issue a Grande Pooh-Bah Declaration that if it is
wise to save daylight
From the listserv list:
Folks still running Windows 2000 should be aware that Windows Update
does not provide a DST fix. You need to go to
http://support.microsoft.com/gp/dst_hu1 to get the tzedit.exe utility
for that purpose.
I am not sure if you need this for XP. That site asks for which
29 matches
Mail list logo
