RE: Time Change

I had the same thing. Just after I posted it to code.midrange.com, I noticed it says it's from Midrange Computing, so I may have just fallen into that same copyright trap.

It's not really that complicated, though. Just check the system date to see if it matches when the time changes and change QHOUR and QUTCOFFSET to the desired values. I don't know how much of the code came from the magazine in December 1997 or if I wrote any of it.

When I say "change" the system values, I really mean add or subtract to avoid problems if it doesn't run when you thought it would. Nothing like scheduling it to run at 0200 and changing the hour to 3 only to find that it didn't run until 0400, and you set the time back instead of forward!

From comment line to ENDPGM, it's only 36 lines and had several blank lines.

No need to check for duplicate run, since the job scheduler won't run the job twice even if the time is set back.
--
Sean Porterfield


-----Original Message-----
From: John Jones
Sent: Thursday, February 16, 2012 21:25
To: Midrange Systems Technical Discussion
Subject: Re: Time Change

That sounds similar to what I wrote, though I did it in just 1 program. It ran every Sunday @ 2AM from the job scheduler and simply checked if it was the right Sunday to spring forward or fall back. If so, it incremented or decremented the system value for the hour. It also had a check to make sure that it hadn't already made a change so it wouldn't make a time change twice.

I may have the source code. I can check tomorrow if there's any interest.
The only updating it would need would be for the new time change dates.

On Thu, Feb 16, 2012 at 4:19 PM, Jim Essinger <dilbernator@xxxxxxxxx> wrote:

Jerry,

I can't believe I still have them, but ...

Before IBM fixed the system to update the time auto-magicly through
system values and such I had a series of programs that when the first
one was called, put itself on the jobq to run on a future date. When
it ran it scheduled itself for the Sunday of the time change, and
changed the time as appropriate. It then scheduled itself for the
next time change cycle. so ..

Spring - Run to get the correct Sunday and schedule the next job.
Spring time change, change the time, then schedule itself to run in
the fall on an appropriate date Fall - Run to get the correct Sunday
and schedule the Fall time change program Fall Time change - Change
the time, and put schedule the spring job.
...
Rinse, repeat.

I still have the CL source (3 programs I believe) to share on an AS IS
basis, if you would like to look at it and get some ideas from it.

Jim

On Thu, Feb 16, 2012 at 9:59 AM, Jerry C. Adams <midrange@xxxxxxxx> wrote:

We're on V5R1 here (with no near term hopes of upgrading hardware or
OS)

so

the change to DST doesn't happen automagically for us.



In the Fall, I just changed the System vale QTIME early Sunday
(we're not
24x7 by any stretch of the imagination) so no user job was impacted.
But Spring may be a different issue.



Anyway, I was reading Bruce, et als, "APIs At Work" tome and came
across the QWCADJTM api. I was wondering if anyone had used (or are
still using)

this

api to adjust the system clock for System i's when on old releases
(such

as

ours) that can't/.won't do it? If so, how did it work out for you?

This email is confidential, intended only for the named recipient(s) above and may contain information that is privileged. If you have received this message in error or are not the named recipient(s), please notify the sender immediately and delete this email message from your computer as any and all unauthorized distribution or use of this message is strictly prohibited. Thank you.