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 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 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 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 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/
[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. The grep cut of PH file below shows relevant parts of the file, namely pairs of lines where - pgm line 438 prints a time stamp - pgm line 439 prints how long it's going to sleep (60 secs) - pgm line 447 sleeps 60 seconds - pgm loops back to line 152 prints the time again The time logged via pgm line 152 MUST be at least 60 seconds later than the previous time logged via pgm line 438. Right? But look at PH lines 113 114. They claim to be only 53 seconds apart. How can that be? Every other loop iteration is exactly as expected. Here's the relevant part of the program: 0151: LOOP 0152: CRT ; CRT TIMEDATE():' loop top.' ; * 2/08 DBG CDS . . . . . . . . . 0438:CRT TIMEDATE():' ': ; * 2/08 DBG CDS 0439:CRT @(10,20):Sleeping for :LOOP.TMR: seconds ... : 0440:CRT @(10,22):Last :RDESC: inbound record processed on 0441:IF REC.DAT = None THEN 0442: CRT (None yet): 0443:END ELSE 0444: CRT OCONV(REC.DAT,D2/): at :OCONV(REC.TIM,MTH): 0445:END 0446: END 0447: SLEEP LOOP.TMR 0448: END 0449: * 0450: REPEAT $cat -n ./FIELD.ESC.PROCESS.LOOP_53693_14653 | grep -eSleeping for -eloop top.| cut -c1-55 60 14:59:35 12 FEB 2008 loop top. 77 15:00:41 12 FEB 2008 Sleeping for 60 seconds ... 78 15:01:41 12 FEB 2008 loop top. 95 15:02:51 12 FEB 2008 Sleeping for 60 seconds ... 96 15:03:51 12 FEB 2008 loop top. 113 15:05:07 12 FEB 2008 Sleeping for 60 seconds ... 114 15:06:00 12 FEB 2008 loop top. 131 15:07:22 12 FEB 2008 Sleeping for 60 seconds ... 132 15:08:22 12 FEB 2008 loop top. 149 15:09:48 12 FEB 2008 Sleeping for 60 seconds ... 150 15:10:48 12 FEB 2008 loop top. 167 15:12:20 12 FEB 2008 Sleeping for 60 seconds ... 168 15:13:20 12 FEB 2008 loop top. 185 15:14:57 12 FEB 2008 Sleeping for 60 seconds ... 186 15:15:57 12 FEB 2008 loop top. (etc. always 60 seconds difference for rest of file) --- 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/
