GMT time vs. local time 
Author Message
 GMT time vs. local time

Any thoughts or comments on how to set the CPU TOD clock?

In the past, I have always set the GMT and local time to the same value,
then said W.00.00.00 in my CLOCKxx member.

We ran an LPAR test today and followed the instructions in one of the red
books.  This caused us to set the TOD clock to GMT.  We had problems with
our JES2 shared spool because the other MAS member had GMT and local time
set to the same value.  It looks like JES2 uses STCK and doesn't adjust
the TOD value by the CVT offset.  This shouldn't be a problem if we set
all of the JES2 MAS guys the same way.

Another problem I noticed with JES2 was with someone we NJE with.  They
must set the two clocks to the correct value, because the job we NJE-ed
to them finished 5 hours before we submitted it.

Any other comments on software and problems when using GMT and local time
set to the correct values.

Thanks.

Mark



Thu, 18 Feb 1999 03:00:00 GMT  
 GMT time vs. local time

Quote:

> .
> .
> .

> Any other comments on software and problems when using GMT and local time
> set to the correct values.

Hi Mark,

We used to set GMT & Local time to same value (W.00.00.00). In Spain we
advance and delay time by one hour at begining of winter and spring,
then we change out GMT time in hardware console and we IPL our systems.
But this year we have change our 9021 by a RX3/R53 and now operators
have not authority to change GMT time in HMC console, so we have set GMT
to correct value and change CLOCK00 to +1/-0 before we IPL the systems.

--
*-----------------------------------------*
*          Salvador Carrasco Gimena       *

*           Ronda (Mlaga) Spain.         *
*-----------------------------------------*
* "My English isn't very good. I'm sorry" *
*-----------------------------------------*



Fri, 19 Feb 1999 03:00:00 GMT  
 GMT time vs. local time

: In the past, I have always set the GMT and local time to the same value,

Why?  Are you in Greenwich?

-- gil



Sat, 20 Feb 1999 03:00:00 GMT  
 GMT time vs. local time

Quote:


> : In the past, I have always set the GMT and local time to the same value,

> Why?  Are you in Greenwich?

> -- gil

I have seen this done at many sites, none of them in Greenwich.
Perhaps it's becase, at least in the past, many people had
a local view of the world, and didn't see what the time in
England had to do with them.  This was especially true before
networking was a big thing, before it was important to be
able to figure out which order three transactions, one in
CA, one in NY, and one in Europe, occurred in.

I ran into a customer the other day who set GMT and local
the same--he set them to both to local time + 12 hours.
I could not get a good explanation of *why* he did this.
I think it was a case of "We've always done it this way."

Lynn Grant



Sat, 20 Feb 1999 03:00:00 GMT  
 GMT time vs. local time

Quote:



>> : In the past, I have always set the GMT and local time to the same value,

>> Why?  Are you in Greenwich?

>> -- gil

>I have seen this done at many sites, none of them in Greenwich.
>Perhaps it's becase, at least in the past, many people had
>a local view of the world, and didn't see what the time in
>England had to do with them.  This was especially true before
>networking was a big thing, before it was important to be
>able to figure out which order three transactions, one in
>CA, one in NY, and one in Europe, occurred in.

>I ran into a customer the other day who set GMT and local
>the same--he set them to both to local time + 12 hours.
>I could not get a good explanation of *why* he did this.
>I think it was a case of "We've always done it this way."

>Lynn Grant


One reason for setting clock to GMT is that you don't have
to dink around with system shutdown twice a year to handle
daylight savings time transitions. Also, if you have to go back in
time and figure out when two events happened, you avoid having
to consider this issue.

Another reason is that, if you are a remote user, it makes
mapping of system time into your local time easier. Otherwise,
you need to know the system's transitions to and from
daylight savings time, as well we those in your own timezone.

I think the approach taken by those who want "local" time
(that is: no remote users in other timezones)
that is most convenient is to set the TOD clock to GMT
(aka UTC), and specify an offset from GMT at IPL time.
I can't remember how this is done, but effectively, there is
a cell in the MVS nucleus containing a value to be added to
the (left half) of the TOD clock value to get "local" time.

Bob



Sun, 21 Feb 1999 03:00:00 GMT  
 GMT time vs. local time

|> I can't remember how this is done, but effectively, there is
|> a cell in the MVS nucleus containing a value to be added to
|> the (left half) of the TOD clock value to get "local" time.
|>

At offset X'130' from the beginning of the CVT, is the field CVTTZ.
It is in units of 1.048576 Seconds. Calculated at NIP time.

This field is in the identical place in CMS' equivalent of a CVT.
(Also picked up from PSA+X'10')

At CVT+X'148' is a pointer to the OS/VS2 Common Extension (CVTEXT2)
At CVTEXT2+X'38' Is another field which is a 'simplified' double-word
value that can be algebraically added to the TOD clock to obtain the
local time. This field is called CVTLDTO. Again, it can also be reached
via identical methods from within CMS.



Sun, 21 Feb 1999 03:00:00 GMT  
 GMT time vs. local time

Quote:

>Any thoughts or comments on how to set the CPU TOD clock?
>In the past, I have always set the GMT and local time to the same value,
>then said W.00.00.00 in my CLOCKxx member.
>We ran an LPAR test today and followed the instructions in one of the red
>books.  This caused us to set the TOD clock to GMT.  We had problems with
>our JES2 shared spool because the other MAS member had GMT and local time
>set to the same value.  It looks like JES2 uses STCK and doesn't adjust
>the TOD value by the CVT offset.  This shouldn't be a problem if we set
>all of the JES2 MAS guys the same way.
>Another problem I noticed with JES2 was with someone we NJE with.  They
>must set the two clocks to the correct value, because the job we NJE-ed
>to them finished 5 hours before we submitted it.
>Any other comments on software and problems when using GMT and local time
>set to the correct values.
>Thanks.
>Mark

Hello Mark, We had similar issues earlier this year when we went to
SYSPLEX. It is not wise to set TOD and Local time equals because the
couple datsets uses the TOD (UTC GMT) time to maintain a time stamp.
Prior to this we always set local and gmt time equals. IBM link has
several helpful  APAR's on this. Search for 'GMT LOCAL TIME CLOCK00 '
To set the TOD or CPU clocks they are only changed when you do a
PWRONRST. We went to the SYSDEF frame of a 9021 class machine and set
the time there to the actual GMT time and set our offset to  4 hours
west of GMT being in Atlanta. We did the same thing in clock 00. From
the SYSDEF frame you are setting the battery clock which is used to
Update the TOD or CPU clock at PWRONRST time. After doing this one
time in the spring all we need to do in the fall is  update the SYSDEF
frame so that the CPU clock is set properly if we ever do another
PWRONRST. Also, we wrote a rexx program that will run twice a year and
update CLOCK00 in parmlib to 5 hours west of GMT in the fall. JES2 and
DB2 also use GMT time for some of there time stamps. Since setting the
CPU clock to GMT is 4 hours ahead we had no problems with DB2 or
SYSPLEX. This way is also the IBM recommendation. Since most logging
software uses GMT time which will never change you don't have as many
issues during the time change season. In the fall it was possible to
get duplicate records if the local time and gmt time were set back an
hour and you did DB2 or ICF catalog processing. A mess if you ever
need to recover.

Let me know if this helps.
l



Mon, 22 Feb 1999 03:00:00 GMT  
 GMT time vs. local time


: > : In the past, I have always set the GMT and local time to the same value,
: > Why?  Are you in Greenwich?

: I have seen this done at many sites, none of them in Greenwich.
: Perhaps it's becase, at least in the past, many people had
: a local view of the world, and didn't see what the time in
: England had to do with them.  This was especially true before
: networking was a big thing, before it was important to be
: able to figure out which order three transactions, one in
: CA, one in NY, and one in Europe, occurred in.

Unfortunately, this local view is still too prevalent.
ISPF timestamps contain local time, not GMT.  There's no
option to use GMT in the timestamp.  CMS timestamps are
local; again no GMT option.  Last time I investigated,
SQL/DS would not let me create a record with a GMT timestamp;
I could only add a GMT stamp in a subsequent update to the
record.  (What does DB2 allow?)  Neither TSO nor CMS
allows users to run sessions with different time zone
offsets on the same host.  (OE presumably fixes this,
but provides no relief for the classic TSO or CMS user.)

I have a modest proposal for the Local to GMT transition:
It should be done as part of the Year 2000 fixes.  By default
all Y2K timestamps should be GMT.  Fix both problems at once.

-- gil



Mon, 22 Feb 1999 03:00:00 GMT  
 GMT time vs. local time



: >> : In the past, I have always set the GMT and local time to the same value,
: >>
: >I have seen this done at many sites, none of them in Greenwich.

: One reason for setting clock to GMT is that you don't have
: to dink around with system shutdown twice a year to handle
: daylight savings time transitions. Also, if you have to go back in
: time and figure out when two events happened, you avoid having
: to consider this issue.

If critical events were stamped with GMT rather than local time,
there would be neither need to shut down for DST transition nor
ambiguity about event timestamps.  Local time should be reserved
for user-friendly displays, but avoided for logging.

: Another reason is that, if you are a remote user, it makes
: mapping of system time into your local time easier. Otherwise,
: you need to know the system's transitions to and from
: daylight savings time, as well we those in your own timezone.

The computer should need to know this, not the human being.
The remote user should be able to specify his preferred time
zone in his profile; the system should handle the offsets
for displayed time automatically, on a use-by-user basis.

OE/Posix handles this properly.  The technology needs to be
retrofitted to classic MVS/TSO and VM/CMS insofar as designers
see a useful life expectancy for classic TSO and CMS in a
world of networks.

-- gil



Mon, 22 Feb 1999 03:00:00 GMT  
 GMT time vs. local time


: SYSPLEX. It is not wise to set TOD and Local time equals because the

Huh!  What if you happen to be in Greenwich?  What else are you supposed
to do?

-- gil



Tue, 23 Feb 1999 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. gmt vs. labview daylight saving time XL

2. pwd.getpw*(), grp.getgr*() and time.{local,gm}time()

3. Compile-time vs Run-time

4. Time scale precision Vs Simulation time

5. Static Timing Analysis vs Timing Simulation

6. Static Timing Analysis vs Timing Simulation

7. cpu time VS. calendar time

8. how to convert current time to gmt?

9. GMT Time

10. gmt time again

11. Getting GMT time

12. Converting time from GMT to another timezone

 

 
Powered by phpBB® Forum Software