RE: [U2] PORT.STATUS bug?
Whate else do people turn to? SYSTEM(9001) is a little different tool, but at least tangential to the current discussion. There is GET.USERS which calls the SYSTEM(1302). SYSTEM(1302) isn't supported by IBM but GET.USERS is. CALL !GET.USERS(PI.USERS,MAX.PI.USERS,SYS.USERS,INFO,CODE) SYS.NB = DCOUNT(INFO,@AM) US = 0 LOOP WHILE US SYS.NB US += 1 SYS.NO.PORT1,US = INFOUS,1 SYS.USERID1,US = INFOUS,2 SYS.PID1,US = INFOUS,3 SYS.TYPE1,US= INFOUS,4 REPEAT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] PORT.STATUS bug?
Scott, We run AIX 5.3 and UniData 6.1.17-64 and we have the same problem with phantoms. What we did is create a baby sitter that stops and starts our phantoms every three hours. In our case is not related to PORT.STATUS, just phantoms hanging. In our case PORT.STATUS is based of the /ud/include/udtconfignfig and the variable is TMP=/flo164/tmp/ Hope this helps. Cheers, Angelo Collazo System Administrator Hi all, HPUX 11 UV10.1.8 Has anyone had any problems with PORT.STATUS causing phantom jobs to hang? We have background jobs that, every once in a while, will hang. When looking at the output from PORT.STATUS the last command is always some simple EXECUTE. For example, the batch job EXECUTES a SH -C ls ./dir/whatever* and, seemingly, fails to return. I did see the following in the PH record :nanosleep: Interrupted system call How does PORT.STATUS work internally anywho? Thanks, Scott --- 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] PORT.STATUS bug?
So if port.status is not a good option for determining what state a process is in, what do people turn to? -- Original message -- From: Stevenson, Charles [EMAIL PROTECTED] I saw something similar with telnet sessions, not phantoms a few years ago. Also HP, but UV 9.6.2.6, HPUX 11, August 2002. I hit it with PORT.STATUS...LAYER.STACK but I don't think I've hit it anywhere else. At least I've never pinned it. It happened when I was trying to collect stats on what we spent our time on. I ran a job that repeatedly executed PORT.STATUS LAYER.STACK (consistent with what Asvin says) and telnet sessions began hanging right left. It was only when I used the LAYER.STACK option and I never saw a problem with phantoms, although several were running, only telnet. I did not see the :nanosleep: Interrupted system call error message. 10.1.14 release notes says: Issue 7659 If 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. There are 4 other notes that mention PORT.STATUS. I did not recognize 7659 as my issue, but reading both of your posts, it looks like maybe it is. I am at UV 10.0.16 at present. Chuck Stevenson From: [EMAIL PROTECTED] this is a known issue in some versions of Universe. It is fixed at one of the 10.1.nnn releases - not sure which. From our experience, it seems to only occur when you have a program that is sleeping, and you run PORT.STATUS more than once without any appreciable gap in between. Sent by:[EMAIL PROTECTED] HPUX 11 UV10.1.8 Has anyone had any problems with PORT.STATUS causing phantom jobs to hang? We have background jobs that, every once in a while, will hang. When looking at the output from PORT.STATUS the last command is always some simple EXECUTE. For example, the batch job EXECUTES a SH -C ls ./dir/whatever* and, seemingly, fails to return. I did see the following in the PH record :nanosleep: Interrupted system call How does PORT.STATUS work internally anywho? Thanks, Scott --- 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] PORT.STATUS bug?
From: [EMAIL PROTECTED] So if port.status is not a good option for determining what state a process is in, what do people turn to? Oh, I still use port.status, including LAYER.STACK, but only from tcl to research a specific issue as it is happening. I haven't tried the mass port.status-layer.stack data collection effort, and I've never seen that problem again. Whate else do people turn to? SYSTEM(9001) is a little different tool, but at least tangential to the current discussion. It will give you the call stack of the current process, similar to what you see with RAID T command or PORT.STATUS LAYER.STACK. So I wrote a subroutine that captures that plus some message you can send it and saves it away for future examination. Suppose I know a certain subroutine occasionally throws errors. Maybe it writes bad data or uv/errlog occasionally shows an input argument unassigned. That subroutine gets called from mutliple places, varying execution levels layers deep. You don't know how it gets to that point. I add this debug logic to the suspect subroutine: IF [condition] THEN CALL *UVDBGLOGGER( control.parameter, [additional message] ) Then I can examine the log and find out who, when, and the call structure. I have thought about having uvdbglogger send email, but so far haven't. I do have a periodic report that gets run and emailed. SYSTEM(9001) is documented in this list's archives. I'll give you the UVDBGLOGGER program to whoever wants it. Chuck Stevenson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] PORT.STATUS bug?
I disagree. Port Status is a good option for determining what the state of a process is if you are on the proper release of the database. We are working on uv 10.1.11 and are not having any problems with PORT.STATUS. You can only have one user in PORT.STATUS at a time, but it works just fine in our environment. (aix 5/2/2UV 10.1.11) Tom Dodds [EMAIL PROTECTED] 708-234-9608 Office 630-235-2975 Cell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 5:27 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] PORT.STATUS bug? So if port.status is not a good option for determining what state a process is in, what do people turn to? -- Original message -- From: Stevenson, Charles [EMAIL PROTECTED] I saw something similar with telnet sessions, not phantoms a few years ago. Also HP, but UV 9.6.2.6, HPUX 11, August 2002. I hit it with PORT.STATUS...LAYER.STACK but I don't think I've hit it anywhere else. At least I've never pinned it. It happened when I was trying to collect stats on what we spent our time on. I ran a job that repeatedly executed PORT.STATUS LAYER.STACK (consistent with what Asvin says) and telnet sessions began hanging right left. It was only when I used the LAYER.STACK option and I never saw a problem with phantoms, although several were running, only telnet. I did not see the :nanosleep: Interrupted system call error message. 10.1.14 release notes says: Issue 7659 If 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. There are 4 other notes that mention PORT.STATUS. I did not recognize 7659 as my issue, but reading both of your posts, it looks like maybe it is. I am at UV 10.0.16 at present. Chuck Stevenson From: [EMAIL PROTECTED] this is a known issue in some versions of Universe. It is fixed at one of the 10.1.nnn releases - not sure which. From our experience, it seems to only occur when you have a program that is sleeping, and you run PORT.STATUS more than once without any appreciable gap in between. Sent by:[EMAIL PROTECTED] HPUX 11 UV10.1.8 Has anyone had any problems with PORT.STATUS causing phantom jobs to hang? We have background jobs that, every once in a while, will hang. When looking at the output from PORT.STATUS the last command is always some simple EXECUTE. For example, the batch job EXECUTES a SH -C ls ./dir/whatever* and, seemingly, fails to return. I did see the following in the PH record :nanosleep: Interrupted system call How does PORT.STATUS work internally anywho? Thanks, Scott --- 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
