Maybe it's not possible for this situation, but when I would test my own
multi-TCB code, I'd add a temporary STIMER WAIT or similar at a point
where a TCB1 was holding whatever TCB2 was trying to get. That would
force TCB2 to wait or fail or whatever it was supposed to do in such a
case. For
On Wed, May 08, 2024 at 12:59:26PM -0400, Tony Harminc wrote:
> On Tue, 7 May 2024 at 01:45, Beate Kawelke
> wrote:
>
> > You could try to directly change the dispatching priority of a TCB with
> > CHAP:
> > https://www.ibm.com/docs/en/zos/2.5.0?topic=hsp-chap-change-dispatching-priority
> >
> >
On Tue, 7 May 2024 at 01:45, Beate Kawelke
wrote:
> You could try to directly change the dispatching priority of a TCB with
> CHAP:
> https://www.ibm.com/docs/en/zos/2.5.0?topic=hsp-chap-change-dispatching-priority
>
> My understanding is that after changing the dispatching priority for your
>
On Mon, May 06, 2024 at 10:34:03PM -0400, Thomas David Rivers wrote:
> We've got a test (with pthread-created TCBs) that we'd like
> to really have dispatched with tiny time slices so we can make
> sure things are working correctly...
>
> But - it seems that all of our time slices are "big"
> so
IEAOPTxx has a TIMESLICES= parameter, but the default is 1 (the minimum).
On Tue, May 7, 2024 at 12:34 PM Thomas David Rivers
wrote:
> We've got a test (with pthread-created TCBs) that we'd like
> to really have dispatched with tiny time slices so we can make
> sure things are working