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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.