let's do the time warp again ! new ECO patch TDF

[Guinaudeau]

I re-open a thread about this issue.

refer also :

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=730417

I am ever interested to exchange experiences for both STD->DST and DST->STD warp and especially for AXP VMS 7.3-2, since it is our
baseline for customer platforms (with some exceptions). Generally, i enjoy this forum and renew my thanks for participants who share their experience at the benefit of the whole VMS community.

Our main application (a product developed on VMS and delivered to circa 15 customers) need full control of the machine clock setting. We
use in the same Alpha cluster both AUTO_DLIGHT_SAV (on the quorum node
only) and application controled setting of the "warp" at time changeover. On every AXP V7.3-2 systems, we defined NET$DISABLE_DTSS in
SYCONFIG.COM and setup using UTC$TIME_SETUP to the correct timezone.

The application calls separately $SETTIM then spawn a script to "warp" at time changeover. This means that we cannot use exactly the example of DAYLIGHT_SAVINGS.COM as provided. Again at that place I have a script with ad hoc calls of UTC$TIME_SETUP. A bit tricky and some tiny troubles in the End of Summer case. The script should run after 03:00 for MET timezone to "see" the correct season. Time 02:00 - 03:00 is a "gray" ambiguous period of time (= in my experience, cell EXE$GQ_TDF may
be updated immediately thru correct UTC$TIME_SETUP call, SYS$TIMEZONE_DIFFERENTIAL cannot be updated immediately, and we need a call of UTC$TIME_SETUP after 03:00 for this).

I have conducted some tests here on a configuration 7.3-2 UPDATE V4.0 plus some more (see attached) and using (at least) a BIND server, DCPS, TNT_SERVER : everything sounds OK, no process loop ... those three have been troublesome in some configurations in the past.

My tests and the experience with last warps by our customers using the release 7.3-2 show at least three variants of behaviour depending
on the patch level of this same release ! Dont know when this will end, but we become very carefull before adding new patches, aware of a
need to check the "warp" behaviour in our environment before installing it by customers.

We have decided for now to keep as close as possible of that baseline, main exceptions have been LAN, FIBRE_SCSI and SHADOW patches to have the expected HP support for some troubles on customer sites in the
last months.

We decided until now not to install V7.3-2 UPDATE V5. Now i read last TDF V3 ECO patch and release notes. Sounds to me (with my experience of changeover with V7.3-2 variants) like some failures may have been reintroduced with UPDATE V5. Release notes do not mention explicitly what it could be, but patch mandatory prerequisite is UPDATE V5.

Release notes problem description :

If an MCR TDF$SET_TIMEZONE MODIFY command is issued after a manual time change to or from daylight saving time, threaded programs will go into an infinite loop.

... a nice effect for our 24/24 SCADA system. We did observe in test these sort of loops for BIND server, DCPS, TNT_SERVER in the past.

===> we manually call the time change with $SETIME and UTC$TIME_SETUP, so we are potentially concerned

===> I would be interested to better understand the reason of this new
TDF V3 patch for V7.3-2 : the true question is whether the trouble came with UPDATE V5. I assume for now that a part of UPDATE V5 brings
another part of VMS in troubles for that issue, is this correct ?

===> I assume that "threaded" programs in the release notes are kernel-threaded processes, not PTHREAD processes. We dont have kernel-threaded processes in the app, but some system services are concerned.

Any informations are welcome.

louis

[Ian Miller.]

It's just a jump to the left :-)

According to http://www.openvms.org/stories.php?story=06/01/20/8195814

"The MODIFY function does not include TDF event change notifications."

and after this patch I guess it does. I think its processes using PTHREADs e.g DCPS e.g. DESTA

[David Sweeney]

The TDF fix in this kit is specific to the MODIFY command of TDF$SET_TIMEZONE. This was not a problem with the update kit, it is a problem specific to TDF in all versions.

>===> we manually call the time change with >$SETIME and UTC$TIME_SETUP, so we are >potentially concerned

If you use UTC$TIME_SETUP then the INITIALIZE command to TDF$SET_TIMEZONE is used not the MODIFY command, so you should be safe. See caveat of one remaining issue on shared condition variables below.

>===> I would be interested to better >understand the reason of this new
>TDF V3 patch for V7.3-2 : the true >question is whether the trouble came with >UPDATE V5. I assume for now that a part of >UPDATE V5 brings
>another part of VMS in troubles for that >issue, is this correct ?

This is not correct.

The V5 update contains other TDF related images, like the jbc$job_control.exe image, that were contained in previous TDF kits. That is why V5 was listed as a prerequisite kit. If you don't take the V5 update kit you will need to install older TDF kits to pickup all the images necessary to fix the various flavors of time change looping problems. I do not know if the older kits are still available.

>===> I assume that "threaded" programs in >the release notes are kernel-threaded >processes, not PTHREAD processes. We dont >have kernel-threaded processes in the app, >but some system services are concerned.

The release note means PTHREAD user threaded processes. I should have made that clear in the note.


There is one remaining bug that will be fixed in a sys kit. If a user threaded application uses SHARED condition variables(CV), and there are timed condition waits on the shared CV, a process loop can occur at the seasonal time change.

Dave

[Ian Miller.]

Re "If a user threaded application uses SHARED condition variables(CV), and there are timed condition waits on the shared CV, a process loop can occur at the seasonal time change."

Does anyone know if this is true for DESTA or DCPS software from hp?

Previously there has been problems with these although on my systems I have not seem problems with the current TDF patches installed.

[Guinaudeau]

dave,

i red your reply and should look at our environment and so on to think
again about the issue with your additional informations, and "adjust"
our way to handle it.

your informations are important precisions for us and for any customer concerned.

thanks for your help !

ian,



Does anyone know if this is true for DESTA or DCPS software from hp?

Previously there has been problems with these although on my systems I have not seem problems with the current TDF patches installed.



that is, TDF V1 and V2 for the release 7.3-2. as previously mentionned, i hope we dont need to install newer patches too in the next two months by every customers to be fully safe.

we observed loop on BIND server and on TNT server too in some systems.

louis

[Guinaudeau]

Dave,

Louis wrote : we observed loop on BIND server and on TNT server too in some systems.

Sorry, I was unclear : previously to UPDATE V4, we did observe process loop in time changeover situations on BIND or TNT servers. But we had another changeover schema, so it is difficult to compare. Currently, the changeover schema of our systems derived from DAYLIGHT_SAVINGS.COM

In our tests of 27th March 2005 time changeover based upon AXP V7.3-2 patch level UPDATE V4 + some few patches (attachment at start of this thread) + DCPS V2.4 + TNT V3.2-D , we did no more observe any process loop or other significant troubles. This is
the release level we have now by our customers. That would mean : in
our case, we do not need to install any new patch, and we will avoid them for stability reasons as long as there are no urgend needs before End of March.

But the tests we can conduct on development systems do not assert this completely, since we cannot easily reproduce the traffic load of production dispatchings. Did we miss during the test something ?

That's why I prefer to ensure further this hypothese (no new patch needed) thru additional informations.

1)

Louis wrote : we manually call the time change with $SETIME then a DCL script calling UTC$TIME_SETUP

more precision about this : most of our systems are in MET timezone, so i take here this example. The DCL script runs eventually with the following schema (nota : our script has been updated too) :

$ if {S->W changeover}
$ then
$ TDF = 60 ! TDF of "MET"
$ else
$ TDF = 120 ! TDF of "MET DST"
$ endif
$ PROC = "SYS$MANAGER:UTC$TIME_SETUP.COM"
$ @'PROC' "" "TDF" 'TDF' 0
$ @'PROC' "" "RULE"

our VMS systems run with MET timezone and adjust twice a year the VMS system clock +1 hour in March (02:00 -> 03:00 drop of one hour), -1 hour in October (at 03:00, warp to 02:00 and clocks runs again from 02:00 to 03:00 for a second time)

the script runs immediately (~ 1 minute) after the changeover occured.

=> are we concerned with that usage of UTC$TIME_SETUP.COM with
TDF$SET_TIMEZONE MODIFY command or not ?

there is an additional subtility in that script : in October, the script runs at 02:01 local time of the machine, then it submits a job at 03:03 local time for the command :

$ @SYS$MANAGER:UTC$TIME_SETUP.COM "" "RULE"

to run again because execution from 02:00 to 03:00 o'clock cannot set correctly every logical names during that "time changeover confusing" period

2)

Dave wrote : the V5 update contains other TDF related images, like the jbc$job_control.exe image, that were contained in previous TDF kits

due to UPDATE V4 patch level, we have installed already TDF V1 and V2. UPDATE V5 contains jbc$job_control.exe image, but link date and identification is not the same as TDF V2.

reading Dave reply, i understand that having TDF V1 and V2 already installed, we might possibly install TDF V3 w/o UPDATE V5, if it
appears that his environment is not enough safe for the changeover.

3)

If a user threaded application uses SHARED condition variables (CV), ...

Dave, do you mean : "user threaded" = "PTHREAD threaded", also when HP delivered (example = BIND) [in opposite to kernel-threaded] ? if this is correct, then i understand Ian's question.

Yours. (and hopefully i am clear enough.)

Louis

[David Sweeney · Accepted solution]

Hi Louis,

Question:
>Sounds to me (with my experience of >changeover with V7.3-2 variants) like some >failures may have been reintroduced with >UPDATE V5.

Answer & Question:
The TDF images supplied in V7.3-2 UPDATE V5 should not replace the TDF images in the TDF V3 ECO kit. Has it been observed that during the UPDATE V5 installation the TDF images from TDF V3 are getting replaced with the Update V5 versions?

Question:
===> we manually call the time change with $SETIME and UTC$TIME_SETUP, so we are potentially concerned
===>

Answer:
Using UTC$TIME_SETUP to adjust the time differential factor, as you state is safe. You should not be concerned.

Question:
===> I would be interested to better understand the reason of this new
TDF V3 patch for V7.3-2 : the true question is whether the trouble came with UPDATE V5. I assume for now that a part of UPDATE V5 brings
another part of VMS in troubles for that issue, is this correct ?
===>

Answer:
Incorrect. The problems fixed in TDF V3 were not introduced in Update V5. VMS itself does not use the MODIFY function of tdf$set_timezone but customers were using it.

Question:
===> I assume that "threaded" programs in the release notes are kernel-threaded processes, not PTHREAD processes. We dont have kernel-threaded processes in the app, but some system services are concerned
===>

Answer:

This means pthread processes. The looping
processes seen in the past have all been symptomatic of thread timers not being adjusted correctly. This has most times been due to the operating system not notifying the threaded process when the differential changed.

I hope this addresses your concerns.

Dave

[Guinaudeau]

Dave,

(Late) thanks for the precisions.

===> The problems fixed in TDF V3 were not introduced in Update V5. VMS itself does not use the MODIFY function of tdf$set_timezone
but customers were using it.

We don't use MODIFY, so we were not concerned with the patch.

===> Using UTC$TIME_SETUP to adjust the time differential factor, as you state is safe. You should not be concerned.

The time changeover did work fine on every customer systems, keeping the level we already had = V7.3-2 UPDATE V4 + some patches (exact list attached at the beginning of this thread). No loops observed on pthread-ed processes. We will continue to use the same mechanism based upon UTC$TIME_SETUP in the future.

===> The TDF images supplied in V7.3-2 UPDATE V5 should not replace the
TDF images in the TDF V3 ECO kit. Has it been observed that during the
UPDATE V5 installation the TDF images from TDF V3 are getting replaced
with the Update V5 versions?

We did not update neither TDF V3 nor update V5 and might upgrade directly with V6.

Louis