If we think about, it, waiting for an IMS call before checking CPU time would
not help stop runaway loops.

Before the IMS tcb does the LINK to the application program it can easily set
an STIMER(N) . It could theoretically also do it via a DIE. Don't recall if
IMS MPPs have a restriction about using STIMER 

On Fri, 26 Jan 2024 18:55:12 +0000 "Schmitt, Michael"
<[email protected]> wrote:

:>In IMS Transaction Manager you can define a PROCLIM for each transaction, 
with a count and/or CPU-time-per-transaction, aka the "processing limit count 
time". The manual says:

:>This is the amount of time (for non-Fast-Path transactions, in seconds; for 
Fast Path transactions, in hundredths of seconds) allowable to process a all 
messages for a given transaction during a single schedule. The number specifies 
the maximum CPU time allowed for each message to be processed in the message 
processing region. The value is a number that can range from 1 to 65 535. 
Specifying the maximum value means that no time limit is placed on the 
application program.

:>When a transaction exceeds the limit IMS abends it with a U0240: "a message 
processing program exceeded the allowable execution time."

:>I swear that it used to be that the calling chain of every U0240 ended in the 
application calling IMS, e.g. a DLI call via CBLTDLI or equivalent. That 
implied that the way it worked was:

:>  *   IMS saves the transaction's CPU time at the start of the transaction 
(or perhaps when the application retrieved its input message).
:>  *   Whenever the application called IMS, IMS would compute the CPU time 
used so far and compare it to the process limit.

:>But now I see U0240's are the result of an interrupt, which can hit anywhere. 
For example, if the application was in it's own code when the time runs out, 
the interrupt fires and IMS then abends with the U0240.

:>What I'm wondering is, why the change?

:>I'm guessing the way it is working now is IMS is setting an STIMER TASK with 
an exit, which measures a 'task-time interval', measured by the CPU timer only 
while the task is in execution.

:>Was that not always an option?

--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to