Re: Changing the system clock this weekend...

Most of Arizona does not observe DST. They could be sitting on a gold
mine. Turn the entire state into a giant data center, we all move our
system there and never have to worry about this again.

neilpalmer400mr@xxxxxxxx 10/26/2006 10:14:59 PM >>>

How about using the new (at V5R3) BCTIMLMT on ENDSBS to do something
like this in a CL programmed submitted to the QCTL job queue (or
whatever your controlling subsystems job queue is - either directly or
from the job scheduler - set to run on the Sunday at 01:57 - and compile
with USRPRF(*OWNER) and make QSECOFR the owner):

PGM

DCL        VAR(&CTLSBS) TYPE(*CHAR) LEN(20)    
DCL        VAR(&CTLSBSD) TYPE(*CHAR) LEN(10)   
DCL        VAR(&CTLSBSLIB) TYPE(*CHAR) LEN(10) 
DCL        &MONTH  *CHAR  2
DCL        &DAY    *CHAR  2

MONMSG CPF0000

*SYSTEM/ENDSBS *ALL *CNTRLD DELAY(150) BCHTIMLMT(65)
DLYJOB DLY(180)

<<==== code for your time system value changes, probably to QHOUR, goes
here (figure out from &MONTH & &DAY what change you're making) 

RTVSYSVAL  QMONTH  &MONTH
RTVSYSVAL  QDAY    &DAY 

OR if using the system value QTIMZON time zone support to adjust, no
code needed, just restart.  If you are changing time back an hour and
don't want to repeat timestamps in files, journals etc., insert another
DLYJOB here to delay until 020001 arrives again, or just a DLYJOB
DLY(3600)  
====>>

RTVSYSVAL  SYSVAL(QCTLSBSD) RTNVAR(&CTLSBS)          
CHGVAR     VAR(&CTLSBSD) VALUE(%SST(&CTLSBS 1 10))   
CHGVAR     VAR(&CTLSBSLIB) VALUE(%SST(&CTLSBS 11 10))

STRSBS: *SYSTEM/STRSBS SBSD(&CTLSBSLIB/&CTLSBSD)
MONMSG     MSGID(CPF1010) THEN(DO) /* Subsystem already active. */
<< insert code here to delay a minute or two if system hadn't yet ended
to restricted starte, then retry the STRSBS  with the GOTO>>
GOTO STRSBS
ENDDO

ENDPGM

This way you make the changes when the system is in a restricted state,
and start up the system after the change, so all jobs, subsystems,
applications, etc. have the correct time.

If things totally screw up in the program, the BCHTIMLMT on the ENDSBS
will bring the system back up 65 minutes after it ends.

(NOTE - the above is NOT tested code)

Neil Palmer, Cambridge, Ontario, Canada

(This account not monitored for personal mail,
remove the last two letters before @ for that)


----- Original Message ----
From: "Graap, Kenneth" <keg@xxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, October 26, 2006 5:19:20 PM
Subject: RE: Changing the system clock this weekend...


I was able to get a hold of a "journaling expert" at IBM who informed
me that my concerns with Application Journaling and system clock time
were unfounded.... This is good news!

Apparently the commitment control mechanism is NOT sensitive to the
timestamps
residing within journal entries.  It is driven, instead, by the CID
field (commit ID
residing within each journal entry).

Recovery processes using journaled transactions are driven by the CID
field too.

The only time timestamp sensitive issue would be issuing an APYJRNCHG
command
starting at a specific point AND specifying a timestamp instead of a
journal 
sequence number. So, setting the time back could affect recovery
procedures in the
event of a disaster recovery, if you had to use timestamp parms with
APYJRNCHG. 

The issue of Job Accounting / Security journal entries and time
sensitive processes like replication software and MQSeries are still a
real concern though. 

Therefore I think I have no choice but to make sure our time change on
Sunday occurs while the system is quiesced.

I'm not sure how I'll handle the QTIMZON system value issue... If you
make any changes to this, for example modifying a time zone description
using iSeries Navigator, the change takes effect immediately!

Therefore, I guess I'll quiesce the system on Sunday, change the
QTIMZON system value, then power off the system, wait an hour and
perform a manual IPL verifying that the time is correct as the system
comes up.

Thanx to all of you for sharing your thoughts on this ... 

One observation... It really shouldn't be this difficult to make a DST
time change on the most advanced application server on the planet. I
hope a future release of OS400 will combine the automated changing to
and from DST, with the "Time Adjustment" feature so we can SCHEDULE a
slow adjustment of the system clock over a few hours... After all, there
will always be time sensitive software and processes running on our
systems. I can only hope that IBM hears my plea. <smile>  

Kenneth