03-30-2005 07:31 AM
Solved! Go to Solution.
03-31-2005 05:27 AM
Would this pin happen to be pin #11? If it is this might be the transaction manager that is taking up the IO. You might want to inquire with the Response Center about increasing the size of the user log for the transaction manager.
03-31-2005 05:12 PM
if the process spends most of its time
waiting for some kind of I/O, it might
help to look at the process stack trace
in Glance to get hints what it might be
waiting for (could be NetIPC sitting in
a socket wait, for example; don't know,
in what category Glance would count it).
03-31-2005 11:49 PM
I've looked in the trace, but it's kind of cryptic at times, I am not too sure what I'm looking at with it.. I will continue to do that and try and pick out some of the more obvious calls in there..
04-06-2005 10:29 AM
oops, yes, the stack trace can be a little cryptic at times; the "interesting" part is
the intrinsic or procedure names on the right
Picking an example from the "System Debug Reference Manual" at http://lrom3k.de.vu ...
*0) SP=40221260 RP=a.00748150 ?FWRITE+$8
export stub: f4.0012d044 P_FLUSHLINE+$54
1) SP=40221260 RP=f4.00139560 P_WRITELN+$20
2) SP=40221200 RP=f4.00139630 P_WRITELN+$9c
3) SP=402211c8 RP=f4.0013950c ?P_WRITELN+$8
export stub: 115.00005e30 student+$10c
4) SP=40221180 RP=115.00006b1c PROGRAM+$300
5) SP=40221100 RP=115.00000000
(end of NM stack)
Here the interesting names, for example,
are FWRITE, P_FLUSHLINE, P_WRITELN, etc.
They indicate that a Pascal writeln() is
calling the FWRITE intrinsic.
If you like, you could share your stack
trace (or traces) with us here to discuss.
04-07-2005 06:18 AM
Here's one trace from today..
Procedure Trace for Pin 257 is:
NM* 0) SP=41858af8 RP=a.0078a004 notify_dispatcher.block_current_process+$338
NM 1) SP=41858af8 RP=a.0078be44 notify_dispatcher+$268
NM 2) SP=41858a78 RP=a.001bba64 wait_for_active_port+$e8
NM 3) SP=41858978 RP=a.001bc6c8 receive_from_port+$544
NM 4) SP=418588f8 RP=a.00759a0c ipc_wait_process+$3b0
NM 5) SP=418586f8 RP=a.00e8a124 tm_msg_var_buf_disc.tm_msg_long_wait+$520
NM 6) SP=418584f8 RP=a.00e91988 tm_msg_var_buf_disc.tm_msg_complete_waited_rea
NM 7) SP=41858378 RP=a.00e92340 tm_msg_var_buf_disc.tm_read+$328
NM 8) SP=418582f8 RP=a.00e93fb0 tm_msg_var_buf_disc+$144
NM 9) SP=41858178 RP=a.0115d090 fread_nm+$95c
NM a) SP=418580b8 RP=a.01439434 FREAD+$d4
NM b) SP=41857c78 RP=a.0143932c ?FREAD+$8
export stub: 124.01098410 FREAD+$588
NM c) SP=41857b78 RP=124.01097e24 ?FREAD+$8
export stub: 596.00056954
NM d) SP=41856938 RP=596.0005798c
NM e) SP=41856838 RP=596.00062c90
NM f) SP=418557b8 RP=596.00062d80
NM 10) SP=41855738 RP=596.00062f74
NM 11) SP=418556f8 RP=596.000baf94
NM 12) SP=41855638 RP=596.00032afc
NM 13) SP=418541b8 RP=596.00000000
04-12-2005 09:00 AM
ah, very helpful stack trace... the program
is sitting inside an FREAD intrinsic call (you
read the stack trace from the bottom up, when
interpreting the nested call sequence)...
And the "tm_msg_var_buf_disc" procedure name
indicates a file system "type manager" for MSG
files... so it seems that Glance counts a wait
on a MSG file as "Other IO".
PS... Inside Glance, you could probably even
look at the open files of the process to find
or guess the message file it is waiting for.
04-12-2005 11:47 PM