Re: Changing the system clock this weekend...

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