Discussion:
Time on one LPAR on CEC
(too old to reply)
Andy
2017-10-08 19:09:54 UTC
Permalink
Raw Message
Hi - I'm not a hardware person, but we have a CEC z13 with multiple LPARS we want 3 of the 6 to run on a different time zone. The system gets STP time through our external CFs.

I'm being told by operations staff who handles the hardware we have to deactivate and reactivate the LPARS running on JAPAN time. These are 3 LPARS we want to be on Japan time since they don't change to daylight savings like the US.

if it helps all the LPARS in question are running z/OS 2.2, they are not all in the same sysplex, two the japan lpars are in a sysplex. One is standalone, the last 3 LPAR(s) are in a sysplex with other systems from other CECs running US time.


In the past the past these LPARS were on their own CEC so this wasn't an issue. This is the first clock change they are all on the same CEC with LPARS running US time, is this how other places handles it with twice the year with the deactivate/activate?

Thanks
Andy
Clark Morris
2017-10-08 20:27:44 UTC
Permalink
Raw Message
[Default] On Sun, 8 Oct 2017 12:09:54 -0700 (PDT), in
Post by Andy
Hi - I'm not a hardware person, but we have a CEC z13 with multiple LPARS we want 3 of the 6 to run on a different time zone. The system gets STP time through our external CFs.
Run all of the LPARs on UTC Universal Time something formerly GMT and
set the time zone offset by LPAR. While there will be problems with
the cutover due to overlapping dates and times, after that most SMF
records will be consistent since most will use the hardware time and
be immune to DST changes. People facing times can be used by the
applications.

Clark Morris
Post by Andy
I'm being told by operations staff who handles the hardware we have to deactivate and reactivate the LPARS running on JAPAN time. These are 3 LPARS we want to be on Japan time since they don't change to daylight savings like the US.
if it helps all the LPARS in question are running z/OS 2.2, they are not all in the same sysplex, two the japan lpars are in a sysplex. One is standalone, the last 3 LPAR(s) are in a sysplex with other systems from other CECs running US time.
In the past the past these LPARS were on their own CEC so this wasn't an issue. This is the first clock change they are all on the same CEC with LPARS running US time, is this how other places handles it with twice the year with the deactivate/activate?
Thanks
Andy
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-10-09 06:39:08 UTC
Permalink
Raw Message
While there will be problems with the cutover due to overlapping dates and times, after that most SMF records will be consistent since most will use the hardware time and be immune to DST changes. People facing times can be used by the applications.
SMF record header timestsmps contain *local* date and time values, not UTC!
-- Peter Hunkeler







----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
White, Andy
2017-10-09 11:23:20 UTC
Permalink
Raw Message
If we run the whole CEC as UTC won't I have to update the clock member on all the ones where there is DST? Now I'm ipling 3 systems (us based) and not having to IPL the Japan supported LPARS?





Run all of the LPARs on UTC Universal Time something formerly GMT and set the time zone offset by LPAR. While there will be problems with the cutover due to overlapping dates and times, after that most SMF records will be consistent since most will use the hardware time and be immune to DST changes. People facing times can be used by the applications.

Clark Morris
Post by Andy
I'm being told by operations staff who handles the hardware we have to deactivate and reactivate the LPARS running on JAPAN time. These are 3 LPARS we want to be on Japan time since they don't change to daylight savings like the US.
The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2017-10-09 15:56:19 UTC
Permalink
Raw Message
Check out the SET TIMEZONE command
-----Original Message-----
On Behalf Of White, Andy
Sent: Monday, October 09, 2017 4:25 AM
Subject: Re: Time on one LPAR on CEC
If we run the whole CEC as UTC won't I have to update the clock member on
all the ones where there is DST? Now I'm ipling 3 systems (us based) and not
having to IPL the Japan supported LPARS?
Run all of the LPARs on UTC Universal Time something formerly GMT and set
the time zone offset by LPAR. While there will be problems with the cutover
due to overlapping dates and times, after that most SMF records will be
consistent since most will use the hardware time and be immune to DST
changes. People facing times can be used by the applications.
Clark Morris
Post by Andy
I'm being told by operations staff who handles the hardware we have to
deactivate and reactivate the LPARS running on JAPAN time. These are 3
LPARS we want to be on Japan time since they don't change to daylight
savings like the US.
The information contained in this message may be CONFIDENTIAL and is for
the intended addressee only. Any unauthorized use, dissemination of the
information, or copying of this message is prohibited. If you are not the
intended addressee, please notify the sender immediately and delete this
message.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-10-09 16:30:49 UTC
Permalink
Raw Message
We run all LPARs on UTC with local time managed by STP. However, the LPAR profile definition screen on HMC includes this:

Clock Type Assignment
_ Standard time of day
_ Logical partition time offset

I believe that this option allows an LPAR to run with a (presumably geographic) offset different from other LPARs on the same CEC. I thought that the option was intended specifically to allow shops to run LPARs in support of various business applications around the world. I have no actual experience here. ;-(

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
Sent: Monday, October 09, 2017 8:58 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Time on one LPAR on CEC

Check out the SET TIMEZONE command
-----Original Message-----
On Behalf Of White, Andy
Sent: Monday, October 09, 2017 4:25 AM
Subject: Re: Time on one LPAR on CEC
If we run the whole CEC as UTC won't I have to update the clock member
on all the ones where there is DST? Now I'm ipling 3 systems (us
based) and not having to IPL the Japan supported LPARS?
Run all of the LPARs on UTC Universal Time something formerly GMT and
set the time zone offset by LPAR. While there will be problems with
the cutover due to overlapping dates and times, after that most SMF
records will be consistent since most will use the hardware time and
be immune to DST changes. People facing times can be used by the applications.
Clark Morris
Post by Andy
I'm being told by operations staff who handles the hardware we have
to
deactivate and reactivate the LPARS running on JAPAN time. These are 3
LPARS we want to be on Japan time since they don't change to daylight
savings like the US.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
George Kozakos
2017-10-09 23:02:43 UTC
Permalink
Raw Message
The Logical partition time offset is used when there is a requirement to
run with
LOCAL = UTC. In that case the LPAR time offset is set to the local time
zone offset
(e.g. +9 hours for Japan) and STPZONE NO, TIMEZONE=W.00.00.00 in CLOCKxx.

If you are running the z/OS systems with a local time zone offset and you
do not
wish to use the time zone specified via STP (e.g. as it is set to the US
time zone)
then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in
CLOCKxx.

Regards,George Kozakos
z/OS Software Service, Level 2 Supervisor
Date: 09/10/2017 12:34 PM
Subject: Re: Time on one LPAR on CEC
We run all LPARs on UTC with local time managed by STP. However, the
Clock Type Assignment
_ Standard time of day
_ Logical partition time offset
I believe that this option allows an LPAR to run with a (presumably
geographic) offset different from other LPARs on the same CEC. I
thought that the option was intended specifically to allow shops to
run LPARs in support of various business applications around the
world. I have no actual experience here. ;-(
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
-----Original Message-----
] On Behalf Of Gibney, Dave
Sent: Monday, October 09, 2017 8:58 AM
Subject: (External):Re: Time on one LPAR on CEC
Check out the SET TIMEZONE command
-----Original Message-----
On Behalf Of White, Andy
Sent: Monday, October 09, 2017 4:25 AM
Subject: Re: Time on one LPAR on CEC
If we run the whole CEC as UTC won't I have to update the clock member
on all the ones where there is DST? Now I'm ipling 3 systems (us
based) and not having to IPL the Japan supported LPARS?
Run all of the LPARs on UTC Universal Time something formerly GMT and
set the time zone offset by LPAR. While there will be problems with
the cutover due to overlapping dates and times, after that most SMF
records will be consistent since most will use the hardware time and
be immune to DST changes. People facing times can be used by the
applications.
Clark Morris
Post by Andy
I'm being told by operations staff who handles the hardware we have
to
deactivate and reactivate the LPARS running on JAPAN time. These are 3
LPARS we want to be on Japan time since they don't change to daylight
savings like the US.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
White, Andy
2017-10-10 11:31:08 UTC
Permalink
Raw Message
Thank you George this will work for us! Andy

If you are running the z/OS systems with a local time zone offset and you do not wish to use the time zone specified via STP (e.g. as it is set to the US time zone) then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in CLOCKxx.

Regards,George Kozakos
z/OS Software Service, Level 2 Supervisor
The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
White, Andy
2017-10-10 13:37:17 UTC
Permalink
Raw Message
George - Does this look right for the clockxx, so we won't use STP at all let the lpar use the system clock?

STPMODE NO
STPZONE NO
ETRMODE NO
ETRZONE NO
TIMEZONE=E.09.00.00
OPERATOR NOPROMPT

---------


The Logical partition time offset is used when there is a requirement to run with LOCAL = UTC. In that case the LPAR time offset is set to the local time zone offset (e.g. +9 hours for Japan) and STPZONE NO, TIMEZONE=W.00.00.00 in CLOCKxx.

If you are running the z/OS systems with a local time zone offset and you do not wish to use the time zone specified via STP (e.g. as it is set to the US time zone) then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in CLOCKxx.

Regards,George Kozakos
z/OS Software Service, Level 2 Supervisor

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Feller, Paul
2017-10-10 16:06:34 UTC
Permalink
Raw Message
Andy, we have STP setup to provide UTC (GMT) to the lpars/hardware. Them we use the offset in the CLOCK member to set the "local" time for the lpars. We have two CECs running lpars on US central time and lpars running on UK time. I hope this helps.

Our CLOCK member for the US lpars with DST:
OPERATOR NOPROMPT
TIMEZONE W.05.00.00
STPMODE YES
STPZONE NO

Our CLOCK member for the UK lpars with DST:
OPERATOR NOPROMPT
TIMEZONE E.01.00.00
STPMODE YES
STPZONE NO

Thanks..

Paul Feller
AGT Mainframe Technical Support

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of White, Andy
Sent: Tuesday, October 10, 2017 08:32
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Time on one LPAR on CEC

George - Does this look right for the clockxx, so we won't use STP at all let the lpar use the system clock?

STPMODE NO
STPZONE NO
ETRMODE NO
ETRZONE NO
TIMEZONE=E.09.00.00
OPERATOR NOPROMPT

---------


The Logical partition time offset is used when there is a requirement to run with LOCAL = UTC. In that case the LPAR time offset is set to the local time zone offset (e.g. +9 hours for Japan) and STPZONE NO, TIMEZONE=W.00.00.00 in CLOCKxx.

If you are running the z/OS systems with a local time zone offset and you do not wish to use the time zone specified via STP (e.g. as it is set to the US time zone) then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in CLOCKxx.

Regards,George Kozakos
z/OS Software Service, Level 2 Supervisor

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
White, Andy
2017-10-10 16:29:02 UTC
Permalink
Raw Message
Thanks Paul and everyone else we got things to work on our lab with the following values, similar to yours Paul

STPMODE YES
STPZONE NO
TIMEZONE=E.09.00.00
OPERATOR NOPROMPT



Andy, we have STP setup to provide UTC (GMT) to the lpars/hardware. Them we use the offset in the CLOCK member to set the "local" time for the lpars. We have two CECs running lpars on US central time and lpars running on UK time. I hope this helps.

Our CLOCK member for the US lpars with DST:
OPERATOR NOPROMPT
TIMEZONE W.05.00.00
STPMODE YES
STPZONE NO

Our CLOCK member for the UK lpars with DST:
OPERATOR NOPROMPT
TIMEZONE E.01.00.00
STPMODE YES
STPZONE NO

Thanks..

Paul Feller
AGT Mainframe Technical Support

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Alan Altmark
2017-10-10 15:51:53 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
Clock Type Assignment
_ Standard time of day
_ Logical partition time offset
I believe that this option allows an LPAR to run with a (presumably geographic) offset different from other LPARs on the same
CEC. I thought that the option was intended specifically to allow shops to run LPARs in support of various business applications
around the world. I have no actual experience here. ;-(
Skip, all of the LPARs should be set to UTC with TOD clock offset 0. Using TOD clock offsets is just a way to let you easily test future events today. "I've got this code that supposed to run on April 1st of every year. Will it?"

To get a different *timezone* in an LPAR, you use the OS's own timezone support. While you CAN get the tz from the hardware as a default, you don't have to.

Alan Altmark
IBM Lab Services
z/VM and Linux

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...