RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
Hey all, Where on IBM's massive web site can I find what was fixed on what version of universe? This thread got me wondering if some weird issues I have seen have already been fixed on a new versions of universe (we are running on AIX if that matters) As well as what new features have been added to new versions of universe Thanks! dougc --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is
Maybe a sys admin changed the system time during the run. Or maybe the system automatically synced to a timeserver. I'll check on that, but I think the synch is automatic and frequent enough to not be off by 7 seconds. Maybe not, since this isn't a production system yet. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is
You might check the system logs; if there was a time server sync there should be a note in there. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
I had a similar experience several years ago (10.0.?/Windows). What I suspect (but never proved) was happening was when I ran PORT.STATUS, it touched the sleeping phantom process and woke it up. It was of little significance to me, and never encounter on other boxes, so I never pursued. You should be able to test easy enough. Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Tuesday, February 12, 2008 4:17 PM To: u2-users@listserver.u2ug.org Subject: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong I've never seen this before. Can anyone explain it? I'm testing UV 10.2.6 on HPUX 11.23, Itanium found this while debugging a program that runs as a phantom. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
-Original Message- From: Mark Eastwood I had a similar experience several years ago (10.0.?/Windows). What I suspect (but never proved) was happening was when I ran PORT.STATUS, it touched the sleeping phantom process and woke it up. It was of little significance to me, and never encounter on other boxes, so I never pursued. You should be able to test easy enough. To test, I had a phantom doing (roughly): loop crt timedate() sleep 60 repeat On a 2nd session I repeatedly did PORT.STATUS PID [phantom's id] That caused the phantom to write out the time every 61 or 62 seconds, but never wake up prematurely. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is
You might check the system logs; if there was a time server sync there should be a note in there. We synch every 10 minutes at 0,10,20,30,40,50 minute mark. That doesn't cover 15:05 where my 7 second glitch happened. I ran a mess of tests overnight. About 200,000 iterations of [time/sleep/time] in all. I read the results this morning programmatically. There were some 1-second anomalies (my smallest measurable granularity). All except 2 spanned a timeserver resynch. Those other 2 each occurred slightly before 01:49:41, in parallel jobs. That's a half minute shy of a time resynch. Each woke up in 9 seconds, not 10. There were 29 other parallel jobs doing exactly the same thing at 1:49 they all behaved appropriately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
If you had a continue or exit in the code above line 439, it would speed up the interval by skipping the sleep on line 439, and depending on what that code was doing, it could take a coincidental 53 seconds. But you said there was none, and there are no double top loop lines, so that situation is moot. -- Louie On Feb 12, 2008 6:05 PM, Stevenson, Charles [EMAIL PROTECTED] wrote: Silly question perhaps, but are there any CONTINUE or EXIT statements in the parts you left out? No, but think about it: even if there were, it could only SLOW DOWN not SPEED UP the interval between executions of CRT TIMEDATE(). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
I see what you're saying. yeah, moot. I was hoping someone would jump in and say they'd seen this before the simple fix is... oh well. thx, cds -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Louie Bergsagel Sent: Wednesday, February 13, 2008 11:53 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong If you had a continue or exit in the code above line 439, it would speed up the interval by skipping the sleep on line 439, and depending on what that code was doing, it could take a coincidental 53 seconds. But you said there was none, and there are no double top loop lines, so that situation is moot. -- Louie On Feb 12, 2008 6:05 PM, Stevenson, Charles [EMAIL PROTECTED] wrote: Silly question perhaps, but are there any CONTINUE or EXIT statements in the parts you left out? No, but think about it: even if there were, it could only SLOW DOWN not SPEED UP the interval between executions of CRT TIMEDATE(). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
There were some changes to do with PHANTOMS being woken from a SLEEP when the parent process terminated. It would be interesting to check your UniVerse release against the Product Availability Matrix: 10.1.14 7659If one UniVerse process was executing a SELECT statement against a file, and a different UniVerse process was executing the PORT.STATUS command, the process selecting the file may have received an error message similar to the following: nanosleep: Interrupted system call This problem was unique to the HP platform and has been fixed. This might be of help - does it match? Regtards JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Eastwood Sent: 13 February 2008 15:10 To: u2-users@listserver.u2ug.org Subject: RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong I had a similar experience several years ago (10.0.?/Windows). What I suspect (but never proved) was happening was when I ran PORT.STATUS, it touched the sleeping phantom process and woke it up. It was of little significance to me, and never encounter on other boxes, so I never pursued. You should be able to test easy enough. Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Tuesday, February 12, 2008 4:17 PM To: u2-users@listserver.u2ug.org Subject: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong I've never seen this before. Can anyone explain it? I'm testing UV 10.2.6 on HPUX 11.23, Itanium found this while debugging a program that runs as a phantom. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is
That seems to support the theory that something else is triggering that wait() to go away, like what someone else had mentioned. I know that's about useless information, but I'm in a uselessly opinionated mood. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
This is on 10.2.6, released Aug 2007. Issue 7659 was fixed in 10.1.14, released Aug 2005. You'd think the fix would be in 10.2.6, too, but maybe it has reared its ugly head again. My description is not quite the same, but I am on HP. No select involved. Executing a PORT.STATUS from another session sounds like something I might have donw. I was examining that program intensely that afternoon. Thanks, JayJay! I'll forward this to support. Chuck -Original Message- From: John Jenkins There were some changes to do with PHANTOMS being woken from a SLEEP when the parent process terminated. It would be interesting to check your UniVerse release against the Product Availability Matrix: 10.1.14 7659If one UniVerse process was executing a SELECT statement against a file, and a different UniVerse process was executing the PORT.STATUS command, the process selecting the file may have received an error message similar to the following: nanosleep: Interrupted system call This problem was unique to the HP platform and has been fixed. This might be of help - does it match? -Original Message- From: Mark Eastwood I had a similar experience several years ago (10.0.?/Windows). What I suspect (but never proved) was happening was when I ran PORT.STATUS, it touched the sleeping phantom process and woke it up. It was of little significance to me, and never encounter on other boxes, so I never pursued. You should be able to test easy enough. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
Silly question perhaps, but are there any CONTINUE or EXIT statements in the parts you left out? When I worked on an AS400 about 10 years ago we had to have the time crystal replaced because it was losing 2 minutes a month. Do computers still have those? -- Louie in Seattle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is
--- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
Silly question perhaps, but are there any CONTINUE or EXIT statements in the parts you left out? No, but think about it: even if there were, it could only SLOW DOWN not SPEED UP the interval between executions of CRT TIMEDATE(). If you look at the line numbers, you'll see that there are no statements missing between line 438 thru 450, then looping back to 151,152. I verified using VLISTt that 450's REPEAT really loops back to 151's LOOP. The only other way would be if there were other lines somewhere else in the program that could be producing that output, but nope: : t Top. : c/loop top/loop top/222 0152: CRT ; CRT TIMEDATE():' loop top.' ; * 2/08 DBG CDS Bottom at line 1017. : t Top. : c/Sleeping for/Sleeping for/22 0439:CRT @(10,20):Sleeping for :LOOP.TMR: seconds ... : Bottom at line 1017. : How does: CRT TIMEDATE() SLEEP 60 CRT TIMEDATE() execute in 53 seconds? Adding other code in between doesn't help. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] SLEEP 60 slept only 53 seconds, or else TIMEDATE() is wrong
I'm going with the vote for a timeserver sync that someone else posted. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
