RE: Time Change -- MIDRANGE-L

I used to run mine every Sunday on the job scheduler. After it worked the first two times, I never looked back. Well, until IBM gave us the right way to do it.
--
Sean Porterfield

-----Original Message-----
From: John Jones
Sent: Friday, February 17, 2012 09:59
To: Midrange Systems Technical Discussion
Subject: Re: Time Change

My code is longer (141 lines with lots of comments & formatting) but the program is forgiving about run circumstances. It's set-n-forget. Run it weekly so you don't have to remember to add it to the scheduler twice a year or do anything funky. Heck, run it daily or hourly; it doesn't care.
If it runs when it shouldn't make a change, nothing happens. Which also means it survives the person trolling the libraries saying "what's this do?". It also handles edge cases where you might want to change the time sometime other than 2AM so as to not disturb other processes.

Overkill? Yes. Excellent code? Probably not. But it worked.

Right now, though, it's coded to the old DST settings of last Sunday in October/first Sunday in April.

On Fri, Feb 17, 2012 at 8:23 AM, Porterfield, Sean < SPorterfield@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

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.