> 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 [email protected] To unsubscribe please visit http://listserver.u2ug.org/
