The program in question implements a sort of application-level record
locking in which a flag field in the database indicates a lock condition.
When this program finds a lock on a record it wants, it's supposed to pause
2 minutes then try again, failing after six tries.  However, for some reason
this particular instance has paused for *way* more than two minutes, even
after I have forcibly cleared the database lock.  I have a call out to the
application vendor to see if they can shed any light, but it seems very
strange that a 2-minute pause would just wait indefinitely.  Does the stack
trace (or any other tool) give us a clue as to what delay value was passed
to the PAUSE intrinsic (i.e. is there a bug in the calling program which
caused it to invoke pause for, say, 2000 minutes instead?)

At 09:06 AM 11/18/97 EST, Pete Crosby wrote:
>John,
>     The process is not really "blocked". It has called PAUSE. My
>suspicion is it is occasionally running, checking for some condition,
>and calling PAUSE again. You will need to check the source for the
>program. "Signal timer wait" means it is on a timer wait (i.e. it has
>called PAUSE) and will be awakened when the timer expires by a message
>being sent to it's signal port.
>
>                                   -Pete Crosby
>                                    HP Atlanta RC
>>
>>We have a job which is stuck.  SOS/3000 says the process is in a "Signal
>>timer wait" and the stack trace shows this:
>>
>>       PC=a.0017470c enable_int+$2c
>>NM* 0) SP=41846ef0 RP=a.002a8a0c notify_dispatcher.block_current_process+$31c
>>NM  1) SP=41846ef0 RP=a.002aae88 notify_dispatcher+$264
>>NM  2) SP=41846e70 RP=a.001a4c20 wait_for_active_port+$ec
>>NM  3) SP=41846d70 RP=a.001a58a0 receive_from_port+$534
>>NM  4) SP=41846cf0 RP=a.00348efc extend_receive+$494
>>NM  5) SP=41846af0 RP=a.001bb2d0 proc_pause+$45c
>>NM  6) SP=41846970 RP=a.001bbccc PAUSE+$584
>>NM  7) SP=418467b0 RP=a.001bb714 ?PAUSE+$8
>>         export stub: ac1.0006ce54
>>NM  8) SP=418464f0 RP=ac1.00000000
>>     (end of NM stack)
>>
>>I have tried :ALTPROC'ing the AID10 process from the DS queue to the CS
>>queue.  Nothing seems to work in getting the process to resume executing.
>>Can any of you help me understand what "Signal timer wait" means, and why
>>the stack trace would show the process "blocked"?  Thanks.
>
>

________________________________________________________
Jon Diercks * Systems Manager         Computing Services
[log in to unmask] (PGP available)     Anderson University
http://rowlf.csv.anderson.edu/        1100 East Fifth St
(765)641-4305 * FAX (765)641-3851     Anderson, IN 46012