Tom writes:


> Listers,
>
> I have three system processes (Pin #61, #62 & #63) that are doing a
> large amount of I/Os (writes).  Below is a listing from SOS of the
> stack trace of one of the pins (Pin #61).  The other pins have the
> same stack trace.  Any ideas?
>
> What is Pin #63 attempting to accomplish?  Is it related to the SQE
> heartbeat problem with DTCs?  The I/Os are strickly Writes and
> sometimes large numbers are displayed (> 1200/sec).

< snip >

>        PC=a.0017770c enable_int+$2c
> NM* 0) SP=416445b0 RP=a.002bcb98 notify_dispatcher.block_current_process+$324
> NM  1) SP=416445b0 RP=a.002bf03c notify_dispatcher+$264
> NM  2) SP=41644530 RP=a.001a7f14 wait_for_active_port+$170
> NM  3) SP=41644430 RP=a.001a8d80 receive_from_port+$7a4
> NM  4) SP=416443b0 RP=a.0035d7e4 extend_receive+$494
> NM  5) SP=416441b0 RP=a.0031a640 freeze_tim+$5e8
> NM  6) SP=41644070 RP=a.0028bcc8 xm_freeze+$98
> NM  7) SP=41643d70 RP=a.002bcb8c notify_dispatcher.block_current_process+$318
> NM  8) SP=41643cf0 RP=a.002bf03c notify_dispatcher+$264
> NM  9) SP=41643c70 RP=a.001a7e90 wait_for_active_port+$ec
> NM  a) SP=41643b70 RP=a.001a8b20 receive_from_port+$544
> NM  b) SP=41643af0 RP=a.0035d7e4 extend_receive+$494
> NM  c) SP=416438f0 RP=a.0101ba78 xm_w_commitrecord+$1a4
> NM  d) SP=416437b0 RP=a.010180e0 xm_end_system_trans+$33c
> NM  e) SP=416436b0 RP=a.0048a2b0 sm_pin_eof+$3dc
> NM  f) SP=416435b0 RP=a.005e2fd8 sm_write_eof+$ac
> NM 10) SP=41643470 RP=a.005e31c8 sm_cntl+$d0
> NM 11) SP=416433f0 RP=a.00c31b00 tm_control_common+$c70
> NM 12) SP=41643330 RP=a.00bf8f64 tm_ord_fix_buf_disc+$250
> NM 13) SP=41643270 RP=a.00eaa950 fcontrol_nm+$d78
> NM 14) SP=416431b0 RP=a.00ea9ba4 ?fcontrol_nm+$8
>          export stub: a.00eab10c FCONTROL+$50
> NM 15) SP=41642db0 RP=a.00eab088 ?FCONTROL+$8
>          export stub: a.0199b40c tio_dtcm.p_write_eof+$f0
> NM 16) SP=41642d30 RP=a.019c6f1c tio_dtcm.x_log+$638
> NM 17) SP=41642cb0 RP=a.019cc1a0 tio_dtcm+$42a0
> NM 18) SP=416424f0 RP=a.019c7eec ?tio_dtcm+$8
>          export stub: a.0038f5d8 io_receive+$ac
> NM 19) SP=41642370 RP=a.00393554 io_mgr_process+$33c
> NM 1a) SP=416422f0 RP=a.0052fa68 outer_block+$14c
> NM 1b) SP=41642130 RP=a.00000000
>      (end of NM stack)
> Enter Command:

I believe that 'tio_dtcm.x_log' is the code that handles X.25 event logging. The
mechanics of the trace (which is sort of odd but more on that later) are that
the process has written a record into a file (the log perhaps) and then calls
FCONTROL to update the EOF. That results in an automatic XM transaction
to protect modification to the file label as the EOF there is changed.

If I'm correct and this is X.25 event logging then maybe there are too many events
being logged or too much X.25 activity resulting in too much logging. Maybe one
of the network gurus here can confirm this.

The oddity in the trace above is from level 7 upwards. I've never seen DEBUG,
assuming SOS calls DEBUG, catch an overlapping trace in quite this way.
Notify_dispatcher does not call xm_freeze. So the trace above is actually a snapshot
of the process state changing quite rapidly. I've just never seen that occur in quite that
way so I thought I'd point that out.  Not a problem, just sort of odd.

Hope this helps,

Bill
HP/CSY