[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

1641.0. "Clocks freeze when set back" by ALLVAX::BEERMAN (Charlie Beerman) Tue Oct 31 1989 08:31

   I, and undoubtedly many U.S. DECwindows workstation users,
   encountered a strange effect yesterday.  After coming in and logging
   on, I found that my system clock needed to be set back due to the
   shift to standard time.

   I set privileges and issued the SET TIME command.  It took effect, as
   evidenced by the output seen after pressing CONTROL-T.  However, the
   clock on my DECwindows Calendar did not change, and the DECwindows
   Banner (CPU usage window) froze.  Since I didn't feel like logging
   out and logging back in again, I decided to wait and see what
   happened.  One hour later, after the system time caught up with the
   time showing on the calendar icon, both the calendar and banner
   resumed normal operation.  On another DECwindows workstation in my
   group, its user commented that the clock tool had frozen as well.

   Why does this happen?  Does the calendar or clock tool not look at
   the system time in order to figure out the time to display?  And how
   does the banner depend on actual system time?

   Note that under UIS the equivalent functionality (Banner with clock)
   reacted immediately to changes in the system time.

T.R	Title	User	Personal Name	Date	Lines
1641.1	Can't remember the real problem, but I know it is discussed	DECWIN::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Tue Oct 31 1989 09:14`	10
	This has been a problem for ages; a search through this and the old DECwindows conference and possibly the calendar conference (and the QAR system) might reveal some additional info. As I remember there is a dispute about who is using absolute time and who is using relative time. (Was this with XtAddInput?). In any case, it certainly happens. It happens with the flashing cursor on DECterm as well, but not with the next widget cursor. Burns
1641.2		MELTIN::dick	Gvriel::Schoeller	`Tue Oct 31 1989 09:28`	8
	What is happening is that clock and calendar are waiting for a timer event to fire. Because the relative times are translated into absolute times by the toolkit, setting the time back causes that timer event to be delayed by an hour. It would be nice if an exposure would cancel the time out, read the actual system time, do the display and submit a new time out. That way iconify/deiconify would reset the time. Dick
1641.3		RIPPLE::FARLEE_KE	Insufficient Virtual...um...er...	`Wed Nov 01 1989 13:04`	9
	>It would be nice if an exposure would cancel the time out, read the >actual system time, do the display and submit a new time out. That way >iconify/deiconify would reset the time. Actually, that worked for the analog clock for me. My assumption is that clock only redraws something if it has moved (timer fired), but on deiconify, it draws everything. Kevin
1641.4		PSW::WINALSKI	Careful with that VAX, Eugene	`Wed Nov 01 1989 16:19`	7
	It's a C RTL bug. The "wait a delta time interval" routine (don't remember its exact name) is implemented by getting the current time of day, adding in the delta, and then doing a $SCHDWK for that time. The routine SHOULD be merely translating the delta time into a VMS delta time and passing that to $SCHDWK. The C RTL developer is aware of this, so it might be fixed in the future. --PSW
1641.5		VIA::FINNEGAN	All of the best intentions are less than one good act.	`Fri Nov 10 1989 16:40`	8
	I have considered doing the expose work around but it seemed like overkill for a RELEASED NOTED problem that only happends once a year. I have QARed this against the toolkit since I ask for a timeout with a relative time of 1 minute and I don't get it for 1 hour and 1 minute is really a toolkit problem. Neal
1641.6	This really needs a fix ASAP.	IO::MCCARTNEY	James T. McCartney III - DTN 381-2244 ZK02-2/N24	`Sat Nov 11 1989 03:04`	10
	I hope that this was QARed as a CRITICAL not just SUGGESTION since it also has impact on realtime and near-realtime applications. I can see it now, set timer for 1 second, start acid flow, await timer, system manager resynchs cluster time which was thirty seconds fast, factory gets melted into slurry... James
1641.7		VIA::FINNEGAN	All of the best intentions are less than one good act.	`Mon Nov 13 1989 09:26`	5
	I QARed thsi about 2 years ago and the intrinsics have not changed so I guess they do not see it quite that seriously. I'll qar it again with a higher priority and see if it gets better response. Neal
1641.8		KONING::KONING	NI1D @FN42eq	`Thu Nov 16 1989 19:08`	9
	The whole point of relative timer requests is that they are meant to be independent of changes to the system time-of-day clock. If that's not what is implemented, it is 100% broken. .6 gives an excellent reason why it must be fixed. If people wanted to have a timer request in absolute time ("wake me at 1:00 am") they would code that! paul
1641.9		PSW::WINALSKI	Careful with that VAX, Eugene	`Wed Nov 22 1989 14:38`	5
	RE: .8 That's right, and the bug is in the C RTL. --PSW