Re: Best way for a task to give up the CPU and let other tasks run?

[Peter Relson]

Enclaves were supposed to be an exception to this rule. First, SRB's in an 
enclave are interruptible. Second, for dispatching purposes, SRB's and 
TCB's placed in an enclave are excluded from the address space. The system 
will select either an enclave or address space for processing.  Time 
slicing applies to the selected enclave or address space (excluding 
enclave SRB's and TCB's). Essentially a single address space acting like 
multiple address spaces. A real solution for a mixed workload address 
space because CHAP and WLM do not solve the problem.

Can you tell us the reality versus what I was told about enclaves?  For 
the the product I worked on, we discussed implementing enclaves but the 
workload could not be classified correctly. I only have research 
experience with WLM enclaves.


This is the 2nd time in a row that you were responding to only part of 
what was written, whether intentionally or not. Yes, enclaves are an 
exception. My "rule" used the term "equal", within "all other things being 
equal". Thus it would not include cases that were unequal, whether that be 
CHAP or enclaves or something else. 

Regardless, your understanding seems flawed.

First, time slicing does not change based on "selected enclave or address 
space".  There may be different time slices for zIIP work vs CP work, or 
when HiperDispatch=YES is in effect vs HiperDispatch=NO. But the time 
slice does not vary based on the enclave or the address space.

Second, everything comes down to priority. WLM does its thing by managing 
the priorities. And dispatch is done based on the resulting priority.

There is a "major priority" (0-255) and a "minor priority" (0-255). Think 
of the major as the address space priority. Think of the minor priority as 
the task priority. Aside from edge cases, things are dispatched in 
priority order. The minor priority comes into play only when comparing 
things with equal major priority.

That leads to the question: where does "enclave priority" fit in? As part 
of "major".  The major priority for a work unit comes from the owning 
enclave (if the work unit is in an enclave) or the owning address space 
(if the work unit is not in an enclave).

When a work unit is undispatched while still ready (I think also for the 
case of "made ready") it is placed at the end of things of equal priority 
(that's how the approximate round-robin is accomplished).

This is not the "complete rule". There are tweaks and exceptions in 
various places.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Jon Perryman]

 

On Sunday, November 3, 2019, 05:38:02 AM PST, Peter Relson 
 wrote:  
 
> all other things being equal, ready tasks within in address space are > 
> dispatched in a round-robin fashion. A time slice is a time slice.

Enclaves were supposed to be an exception to this rule. First, SRB's in an 
enclave are interruptible. Second, for dispatching purposes, SRB's and TCB's 
placed in an enclave are excluded from the address space. The system will 
select either an enclave or address space for processing.  Time slicing applies 
to the selected enclave or address space (excluding enclave SRB's and TCB's). 
Essentially a single address space acting like multiple address spaces. A real 
solution for a mixed workload address space because CHAP and WLM do not solve 
the problem.

Can you tell us the reality versus what I was told about enclaves?  For the the 
product I worked on, we discussed implementing enclaves but the workload could 
not be classified correctly. I only have research experience with WLM enclaves.

Jon.   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Peter Relson]

> If the two parties are running in different address spaces then a 
> complaint could only be that the address space is consuming a lot of 
CPU 
> and that is exactly what WLM goals and priorities are for.
Only true if you ignore mixed workload address spaces


Perhaps you did not read that my sentence started with an "if". Yes, 
specifically because of the "if", I am ignoring mixed workload address 
spaces.


The OP has a known rogue TCB in a multi-tasking address space otherwise 
why did he ask the question. 


That was specifically not the case according to one post. The poster had a 
CPU-intensive process and was trying to be a responsible program.

The question of how to deal with intra-address space priorities could be 
things such as CHAP and enclaves.
And even then, a "rogue TCB" within an address space will not take more 
than its share of all tasks of that address space because, all other 
things being equal, ready tasks within in address space are dispatched in 
a round-robin fashion. A time slice is a time slice.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Jon Perryman]

 On Wednesday, October 30, 2019, 05:50:04 AM PDT, Peter Relson 
 wrote:
 
,> If the two parties are running in different address spaces then a 

> complaint could only be that the address space is consuming a lot of CPU 

> and that is exactly what WLM goals and priorities are for.


Only true if you ignore mixed workload address spaces (E.g. DB2, MQ, databases, 
automation, Websphere, Unix, IMS, CICS and probably others). WLM and priorities 
do not automatically deal with these situations. DB2 solved this problem by 
implementing WLM enclaves into the product. Other products have implemented 
strategies that don't involve WLM.

> And the on-point responses were not to worry because time-slicing and WLM 

> etc etc would deal with that..

I have to disagree. Cheryl Watson and her team exist because time-slicing and 
WLM don't magically solve every issue. Instead you must be proactive. The OP 
has a known rogue TCB in a multi-tasking address space otherwise why did he ask 
the question. At the very least, he needs to consider it's impact when CPU 
approaches 100%.

Jon.   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Peter Relson]

>I believe the OP mentioned he received complaints that his 
>task was hogging the CPU.

I went back and looked. The OP said no such thing


One of the posters (I thought the OP) mentioned that they were just trying 
to be a good guy, amidst a lengthy period of intensive CPU usage, of 
trying to yield occasionally, in the best interests of the system.

And the on-point responses were not to worry because time-slicing and WLM 
etc etc would deal with that..

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Thomas David Rivers]

Thomas David Rivers wrote:


Does anyone happen to know the best way for a running task
to give up running and let another task run?

But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.

Sorta like "I'm done for the moment if something else would like to run".

  - Thanks -
   - Dave R. -


*Many* thanks to all of those who took a moment to respond!

I didn't mean to leave people hanging about the reason for this
question; let me just say "customer request"... which really doesn't
go too far down the road of explanation, I know...

You know the saying "Not my circus, not my monkeys?"   Well, in this
case, it's "Not our circus" - but it is our monkeys :-)  And, we have to 
make

sure they behave as requested.

  - Dave Rivers -


--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Tom Marchant]

On Tue, 29 Oct 2019 17:43:25 +, Jon Perryman wrote:

>I believe the OP mentioned he received complaints that his 
>task was hogging the CPU.

I went back and looked. The OP said no such thing. In fact, the 
OP has said nothing about why he wants to do this, despite 
being asked no less than four times and considerable speculation.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Peter Relson]

I believe the OP mentioned he received complaints that his task was 
hogging the CPU. 


It would be unusual for "someone" to get complaints from "someone else" 
about a task owned by that "someone", unless both the "someone" and the 
"someone else" were running in the same address space at the same time. 
And that doesn't happen all that often, does it?

If the two parties are running in different address spaces then a 
complaint could only be that the address space is consuming a lot of CPU 
and that is exactly what WLM goals and priorities are for.

It is not overly helpful to guess. The OP could clarify...

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Jon Perryman]

 On Wed, 23 Oct 2019 18:23:31 +, Seymour J Metz wrote:

>The Dispatcher has been using timers for decades. What interrupts your 
>code is an external event from a timer or from a SIGP on another CPU.


>If you're running with appropriate goals, don't try to second guess WLM.

I believe the OP mentioned he received complaints that his task was hogging the 
CPU. WLM does not cover every situation. I'm guessing that changing the WLM 
goals did not solve the problem since that would be the first thing most people 
consider when this situation occurs. The most obvious situation is with 
multiple active TCB's in an address space because WLM does not directly deal 
with TCB priority.

I think the op should look at the CHAP macro and implementing WLM enclaves. 
CHAP would be simpler but I suspect that enclaves will probably be the more 
appropriate solution. CALLDISP probably won't be necessary but that really 
depends upon the situation.

Jon.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Tom Marchant]

On Wed, 23 Oct 2019 18:23:31 +, Seymour J Metz wrote:

>The Dispatcher has been using timers for decades. What interrupts your 
>code is an external event from a timer or from a SIGP on another CPU.

>If you're running with appropriate goals, don't try to second guess WLM.

I agree. The OP has yet to give any indication of why he wants to do this, 
despite being asked repeatedly, and considerable speculation.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Seymour J Metz]

The Dispatcher has been using timers for decades. What interrupts your code is 
an external event from a timer or from a SIGP on another CPU.

 If you're running with appropriate goals, don't try to second guess WLM.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Saturday, October 19, 2019 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Great descriptions!  I was thinking of the PI calculation myself because
that's a case where you're doing real work, but the loop could be coded
with no I/O and no SVC calls (which would give up control).  Now here's
a case I thought about in the past:  Assuming I'm running such a PI
calculation (non-supervisor, interrupts enabled), what is it that
eventually interrupts my running code?  Of course there are previous I/O
completions from other tasks or CP's, but imagine (maybe on a
specialized system?) there's nothing much else going on.  Is there
something in the dispatcher that is on a timer that ends up saying this
task has gotten enough CPU and it's time to move to the next TCB?

On 10/19/2019 7:45 AM, Charles Mills wrote:
> Others have given you good replies. I've been thinking about your question
> and thought I would summarize and re-phrase what has been said. You are not
> very specific in what your situation is, so let me offer three possible
> problem scenarios, each with its own solution.
>
> I. "I am doing something that is going to require a whole lot of processing,
> like computing pi to a million digits. It occurs to me that I have been
> processing for quite some time. I would like to be polite and give others a
> chance."
>
> Solution: Do nothing special. This is the magic of MVS and WLM. Assuming WLM
> is set up properly, and you are in an appropriate WLM class, then when their
> algorithms decide that someone else deserves to run, they will get to run,
> and then after a while you will run again, all seamlessly and transparently,
> with no effort on your part. (If that assumption is wrong, then you need to
> fix that.)
>
> II. "My code handles something that happens from time to time, like a
> transaction coming in on the wire. There is no work to do at the moment but
> there may be shortly."
>
> Solutions: (a.) Look first at WAIT and POST. WAIT will let your task give up
> the CPU until whatever process gives you work indicates that there is
> something to do, with POST.
>
> (b.) If you do not have control of the process that gives you work to do and
> so cannot add a POST to it -- perhaps you are monitoring jobs in other
> address spaces and watching for something to happen there -- then look at
> STIMER WAIT. That will let you give up the CPU for a tenth of a second or
> ten seconds or whatever is appropriate.
>
> (c.) If there is plenty of work to do, but you need some resource that is
> currently unavailable -- a file or a common buffer or something like that --
> to be able to do it, then look at ENQ and DEQ. They will let you give up the
> CPU until the process that is using the common resource relinquishes it.
>
> In other words, there is no single magic "umm, I have nothing to do for a
> little while; come back to me when I do" service available in MVS without
> your specifying a little better what the condition is that will constitute
> "something to do."
>
> III. "Everything you say is well and good, but my code is running in an MVS
> exit, or as an SRB, or holds locks, or something like that, which precludes
> the use of WAIT and similar services." I think this is not likely your
> situation but for completeness I will cover it.
>
> Solution: yes, take a look at CALLDISP as others have suggested. It's not
> the right solution if I. or II. is your situation, but if III. applies, then
> yes, this is a possible answer to your question.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas David Rivers
> Sent: Thursday, October 17, 2019 8:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best way for a task to give up the CPU and let other tasks run?
>
> Does anyone happen to know the best way for a running task
> to give up running and let another task run?
>
> But - this isn't "give up" as in ending the task, just giving up
> the CPU to allow another task to run and then returning to this
> task.
>
> Sorta like "I'm done for the moment if something else would like to run".
>
> - Thanks -
>  - Dave R. -
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: Best way for a task to give up the CPU and let other tasks run?

[Seymour J Metz]

External Interrupt has always been a grab bag, even on S/360. S/370 added more 
events that I wouldn't describe as external. The list is pretty long these days.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Saturday, October 19, 2019 7:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Interesting, thanks!  So it generates an external interrupt.  I always
thought that one was only for the external interrupt "key", but this
page indicates CPU timer and some kind of CP-to-CP communication too:

https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_interrupts.htm

Ok... now back to my weekend work, like changing the oil in my truck.

On 10/19/2019 3:54 PM, Charles Mills wrote:
> Check out "CPU Timer" in the Principles of Operation.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Charles Mills
> Sent: Saturday, October 19, 2019 12:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way for a task to give up the CPU and let other tasks run?
>
> Thanks!
>
> I suppose some encryption algorithm for which there was no hardware assist 
> available might be a more practical real-world scenario.
>
>> Is there something in the dispatcher that is on a timer that ends up saying 
>> this task has gotten enough CPU and it's time to move to the next TCB?
>
> In my way imperfect understanding, yes. I believe there is a hardware feature 
> now wherein MVS can say "give me an interrupt when this CPU has run for nnn 
> CPU microseconds" or something similar.
>
> If not, then most operating systems have a concept of the time slice: we will 
> let set a hardware timer for nnn real-time microseconds and when the timer 
> goes off, re-evaluate our scheduling algorithm.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Tom Brennan
> Sent: Saturday, October 19, 2019 12:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way for a task to give up the CPU and let other tasks run?
>
> Great descriptions!  I was thinking of the PI calculation myself because
> that's a case where you're doing real work, but the loop could be coded
> with no I/O and no SVC calls (which would give up control).  Now here's
> a case I thought about in the past:  Assuming I'm running such a PI
> calculation (non-supervisor, interrupts enabled), what is it that
> eventually interrupts my running code?  Of course there are previous I/O
> completions from other tasks or CP's, but imagine (maybe on a
> specialized system?) there's nothing much else going on.  Is there
> something in the dispatcher that is on a timer that ends up saying this
> task has gotten enough CPU and it's time to move to the next TCB?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Seymour J Metz]

If you use your own spin loop (as opposed to a spin lock) and the lock is held 
by another task, then dispatching delays for that task will delay you, driving 
up the CPU consumption. The Devil is in the details, but I have yet to see a 
case where it is warranted.

What I have seen is a case where you may be able to do an atomic update with no 
OS involvement most of the time, but fall back to OS mediated synchronization 
when all else fails.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Monday, October 21, 2019 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

(Now with some actual content.) The standard justification for spin loop is 
that the area of code in question is executed *very* frequently and is *very* 
short. In other words, not worth the overhead of an actual WAIT nor the delay 
in  having to get redispatched afterwards. Spin loop is not an ideal strategy 
but--as long as all goes well--worth the improved performance overall. The 
biggest problem with spin loop is on a single CP machine when the loop does not 
terminate properly. If a second CP is available, it can jump in and interrupt 
the loop. With no second CP in the picture, the loop may go on and on.

That being said, I can't imagine an application program using this mechanism. 
OTOH, the line between 'problem program' and 'middleware' (akin to OS) can be 
pretty fuzzy. OP, however, said he wanted to yield CPU to other tasks. Spin 
loop is designed not to yield to anyone.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Monday, October 21, 2019 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Best way for a task to give up the CPU and let other 
tasks run?

On Sun, 20 Oct 2019 at 02:32, David Crayford  wrote:

> The only code I've seen that implements yield are synchronization
> routines. Consider a spin-lock which is spinning on a CS instruction.

Why would any application program on z/OS implement and use a spin lock? Why do 
the authors of such think they can do a better implementation than the 
operating system?

If you think you need a spin lock on z/OS, you should probably be using 
transactional execution.

Tony H.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

Thank you Peter for the great comments!

On 2019-10-23 8:34 PM, Peter Relson wrote:


The code snippets I posted show that the code sleeps rather than waiting
to be signaled which I suspect may be cheaper on those platforms.

I don't know about the relative cheapness, but generally sleeping (and
looking again when you wake up) is easier, and waiting/posting
(pausing/releasing) is more responsive.


I've mostly seen user-space spin-locks in Linux (maybe should be called 
busy-wait loops) for use-cases like lock per bucket list in a hash table.
Maybe using a kernel lock is more expensive in this case because the 
lock should be short lived and when contention does occur a context switch
would be more expensive then spinning WRT latency. The locks generally 
back-off into hardware instruction pauses and/or timer waits.


It's probably a case of "horses for courses"! z/OS is optimized for 
batch/transactions workloads where an OS like Linux runs on many 
different devices.
We would all be pretty miffed if streaming Netflix from our phones 
lagged because it's being frequently preempted :)





This is quite common in the assembler code I see. A CS loop with a timer

I presume you mean a CS loop that continues to loop even if the starting
condition does not change, but after a while sleeps.


Is "priority inversion" not an issue on z/OS. I know that swapped out
address spaces go to the top of the dispatcher queue but
how does it work for tasks?

Of course it's an issue. In some cases, the operating system can help. In
others, the (authorized) application must do it. I say "authorized"
because priority inversions in z/OS are typically multi-address-space
issues, because the default for tasks in an address space is that they all
run at the same priority.


You can call CHAP.

You can call it but it won't in general do anything to help a priority
inversion case, unless it's to help a problem that you introduced by
previous use of CHAP. CHAP is for creating your own intra-address space
priorities.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Peter Relson]

The code snippets I posted show that the code sleeps rather than waiting 
to be signaled which I suspect may be cheaper on those platforms.

I don't know about the relative cheapness, but generally sleeping (and 
looking again when you wake up) is easier, and waiting/posting 
(pausing/releasing) is more responsive.


This is quite common in the assembler code I see. A CS loop with a timer 

I presume you mean a CS loop that continues to loop even if the starting 
condition does not change, but after a while sleeps.


Is "priority inversion" not an issue on z/OS. I know that swapped out 
address spaces go to the top of the dispatcher queue but
how does it work for tasks?

Of course it's an issue. In some cases, the operating system can help. In 
others, the (authorized) application must do it. I say "authorized" 
because priority inversions in z/OS are typically multi-address-space 
issues, because the default for tasks in an address space is that they all 
run at the same priority.


You can call CHAP. 

You can call it but it won't in general do anything to help a priority 
inversion case, unless it's to help a problem that you introduced by 
previous use of CHAP. CHAP is for creating your own intra-address space 
priorities. 

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

Thank you, Don!

On 2019-10-22 8:37 PM, Don Poitras wrote:

And for things like "enabled resources" (ENQ, LOCAL lock), the system may
attempt to manage the work unit priorities to give the "holder" some extra
CPU time.

This is interesting for ENQ. Windows has a mechanism in place to raise
the priority of waiters to mitigate "priority inversion".
https://docs.microsoft.com/en-us/windows/win32/procthread/priority-inversion
Is "priority inversion" not an issue on z/OS. I know that swapped out
address spaces go to the top of the dispatcher queue but
how does it work for tasks?

You can call CHAP.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa700/chap.htm


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Don Poitras]

In article  you wrote:
> On 2019-10-22 7:42 PM, Peter Relson wrote:
> > You can spin for a while, but then really need to "wait" (or pause) until
> > "posted" (or released) when the resource becomes available..
> The code snippets I posted show that the code sleeps rather than waiting 
> to be signaled which I suspect may be
> cheaper on those platforms.
> > Note that this is not the same as a CS loop which loops until successful
> > but only re-does things if something has changed.
> This is quite common in the assembler code I see. A CS loop with a timer 
> (but no wait/post backoff).
> >
> > And for things like "enabled resources" (ENQ, LOCAL lock), the system may
> > attempt to manage the work unit priorities to give the "holder" some extra
> > CPU time.
> This is interesting for ENQ. Windows has a mechanism in place to raise 
> the priority of waiters to mitigate "priority inversion".
> https://docs.microsoft.com/en-us/windows/win32/procthread/priority-inversion
> Is "priority inversion" not an issue on z/OS. I know that swapped out 
> address spaces go to the top of the dispatcher queue but
> how does it work for tasks?

You can call CHAP.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa700/chap.htm

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

On 2019-10-22 7:42 PM, Peter Relson wrote:


You can spin for a while, but then really need to "wait" (or pause) until
"posted" (or released) when the resource becomes available..



The code snippets I posted show that the code sleeps rather than waiting 
to be signaled which I suspect may be

cheaper on those platforms.



Note that this is not the same as a CS loop which loops until successful
but only re-does things if something has changed.



This is quite common in the assembler code I see. A CS loop with a timer 
(but no wait/post backoff).





And for things like "enabled resources" (ENQ, LOCAL lock), the system may
attempt to manage the work unit priorities to give the "holder" some extra
CPU time.


This is interesting for ENQ. Windows has a mechanism in place to raise 
the priority of waiters to mitigate "priority inversion".


https://docs.microsoft.com/en-us/windows/win32/procthread/priority-inversion

Is "priority inversion" not an issue on z/OS. I know that swapped out 
address spaces go to the top of the dispatcher queue but

how does it work for tasks?



Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Peter Relson]

My advice: Do Not Spin.

If your implementation of a "lock" is to loop until it is available, you 
are pretty much doomed to failure in some edge cases over which you likely 
have no control. 

You can spin for a while, but then really need to "wait" (or pause) until 
"posted" (or released) when the resource becomes available..

Note that this is not the same as a CS loop which loops until successful 
but only re-does things if something has changed. 

If you can do things with transactional execution, that can be great 
(especially constrained transactions which require no fallback path). And 
as of z/OS 2.4 you can rely on that functionality being available, 
regardless of whether your z/OS is running under zVM or not.

The operating system's spin locks are done by spinning while disabled for 
external and I/O interrupts (well not exactly, because they open "windows" 
to allow certain external interrupts, such as those from SIGP's, in -- 
this important for the well-being of the system). 

And for things like "enabled resources" (ENQ, LOCAL lock), the system may 
attempt to manage the work unit priorities to give the "holder" some extra 
CPU time.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

On 2019-10-22 12:09 PM, Mike Hochee wrote:

Define application program? COBOL batch or CICS transaction program?
Most legacy applications on z/OS don't implement concurrency.

Agreed, they don't implement concurrency, however they are often very heavily 
reliant upon on it, as it is built into the database management and message 
queuing systems they access (whether the programmer is aware of it or not). As 
a result, workloads generally move right along.


Yep. And considering how difficult it is to do concurrency correctly 
that's a good thing.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Monday, October 21, 2019 11:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Caution! This message was sent from outside your organization.

On 2019-10-22 1:55 AM, Tony Harminc wrote:

On Sun, 20 Oct 2019 at 02:32, David Crayford  wrote:


The only code I've seen that implements yield are synchronization
routines. Consider a spin-lock which is spinning on a CS instruction.

Why would any application program on z/OS implement and use a spin
lock?

Define application program? COBOL batch or CICS transaction program?
Most legacy applications on z/OS don't implement concurrency.

Porting modern code is another matter. You may find a lot of the new ported 
code like Node.js (V8), libuv etc implement their own locks.


Why do the authors of such think they can do a better implementation
than the operating system?

Maybe using SETLOCK (which requires supervisor state, key 0) is an obstacle?


If you think you need a spin lock on z/OS, you should probably be
using transactional execution.

Yes, I agree. But it's quite tricky to grok and you need to crack open the 
assembler!

There's an example of a lock-free queue using transactional execution in Zowe

https://github.com/zowe/zowe-common-c/blob/719251839033059fb3b507f26f6fbb58be57f188/c/collections.c#L1123


Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Mike Hochee]

> Define application program? COBOL batch or CICS transaction program?
> Most legacy applications on z/OS don't implement concurrency.

Agreed, they don't implement concurrency, however they are often very heavily 
reliant upon on it, as it is built into the database management and message 
queuing systems they access (whether the programmer is aware of it or not). As 
a result, workloads generally move right along.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Monday, October 21, 2019 11:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Caution! This message was sent from outside your organization.

On 2019-10-22 1:55 AM, Tony Harminc wrote:
> On Sun, 20 Oct 2019 at 02:32, David Crayford  wrote:
>
>> The only code I've seen that implements yield are synchronization 
>> routines. Consider a spin-lock which is spinning on a CS instruction.
> Why would any application program on z/OS implement and use a spin 
> lock?

Define application program? COBOL batch or CICS transaction program?
Most legacy applications on z/OS don't implement concurrency.

Porting modern code is another matter. You may find a lot of the new ported 
code like Node.js (V8), libuv etc implement their own locks.

> Why do the authors of such think they can do a better implementation 
> than the operating system?

Maybe using SETLOCK (which requires supervisor state, key 0) is an obstacle?

>
> If you think you need a spin lock on z/OS, you should probably be 
> using transactional execution.

Yes, I agree. But it's quite tricky to grok and you need to crack open the 
assembler!

There's an example of a lock-free queue using transactional execution in Zowe

https://github.com/zowe/zowe-common-c/blob/719251839033059fb3b507f26f6fbb58be57f188/c/collections.c#L1123

>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

On 2019-10-22 1:55 AM, Tony Harminc wrote:

On Sun, 20 Oct 2019 at 02:32, David Crayford  wrote:


The only code I've seen that implements yield are synchronization
routines. Consider a spin-lock which is spinning on a CS instruction.

Why would any application program on z/OS implement and use a spin
lock?


Define application program? COBOL batch or CICS transaction program? 
Most legacy applications on z/OS don't implement concurrency.


Porting modern code is another matter. You may find a lot of the new 
ported code like Node.js (V8), libuv etc implement their own locks.



Why do the authors of such think they can do a better
implementation than the operating system?


Maybe using SETLOCK (which requires supervisor state, key 0) is an 
obstacle?




If you think you need a spin lock on z/OS, you should probably be
using transactional execution.


Yes, I agree. But it's quite tricky to grok and you need to crack open 
the assembler!


There's an example of a lock-free queue using transactional execution in 
Zowe


https://github.com/zowe/zowe-common-c/blob/719251839033059fb3b507f26f6fbb58be57f188/c/collections.c#L1123



Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Paul Gilmartin]

On Mon, 21 Oct 2019 19:01:15 +, Jesse 1 Robinson wrote:

>(Now with some actual content.) The standard justification for spin loop is 
>that the area of code in question is executed *very* frequently and is *very* 
>short. 
>
I'd say, rather, the typical *wait* is *very* short.

>... In other words, not worth the overhead of an actual WAIT nor the delay in  
>having to get redispatched afterwards. Spin loop is not an ideal strategy 
>but--as long as all goes well--worth the improved performance overall. The 
>biggest problem with spin loop is on a single CP machine when the loop does 
>not terminate properly. If a second CP is available, it can jump in and 
>interrupt the loop. With no second CP in the picture, the loop may go on and 
>on. 
> 
Deadlock?  The likelihood goes down with the number of CPUs.  But that's
what dooms the strategy of STIMER and retry (akin to a slow spin) to
resolve DSN ENQ.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Jesse 1 Robinson]

(Now with some actual content.) The standard justification for spin loop is 
that the area of code in question is executed *very* frequently and is *very* 
short. In other words, not worth the overhead of an actual WAIT nor the delay 
in  having to get redispatched afterwards. Spin loop is not an ideal strategy 
but--as long as all goes well--worth the improved performance overall. The 
biggest problem with spin loop is on a single CP machine when the loop does not 
terminate properly. If a second CP is available, it can jump in and interrupt 
the loop. With no second CP in the picture, the loop may go on and on. 

That being said, I can't imagine an application program using this mechanism. 
OTOH, the line between 'problem program' and 'middleware' (akin to OS) can be 
pretty fuzzy. OP, however, said he wanted to yield CPU to other tasks. Spin 
loop is designed not to yield to anyone.   

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Monday, October 21, 2019 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Best way for a task to give up the CPU and let other 
tasks run?

On Sun, 20 Oct 2019 at 02:32, David Crayford  wrote:

> The only code I've seen that implements yield are synchronization 
> routines. Consider a spin-lock which is spinning on a CS instruction.

Why would any application program on z/OS implement and use a spin lock? Why do 
the authors of such think they can do a better implementation than the 
operating system?

If you think you need a spin lock on z/OS, you should probably be using 
transactional execution.

Tony H.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Jesse 1 Robinson]

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Monday, October 21, 2019 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Best way for a task to give up the CPU and let other 
tasks run?

On Sun, 20 Oct 2019 at 02:32, David Crayford  wrote:

> The only code I've seen that implements yield are synchronization 
> routines. Consider a spin-lock which is spinning on a CS instruction.

Why would any application program on z/OS implement and use a spin lock? Why do 
the authors of such think they can do a better implementation than the 
operating system?

If you think you need a spin lock on z/OS, you should probably be using 
transactional execution.

Tony H.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Tony Harminc]

On Sun, 20 Oct 2019 at 02:32, David Crayford  wrote:

> The only code I've seen that implements yield are synchronization
> routines. Consider a spin-lock which is spinning on a CS instruction.

Why would any application program on z/OS implement and use a spin
lock? Why do the authors of such think they can do a better
implementation than the operating system?

If you think you need a spin lock on z/OS, you should probably be
using transactional execution.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Sean Gleann]

Back in the days of IPS/ICS dispatching control, wasn't there something
that was referred to as the 'wheeler-dealer mechanism' & does it still
exist in some form in the WLM code?
>From memory:
1. New task gets created and is assigned a time-slice of 1msec, at a
priority of 32 (out of 64 - i.e  'half'), then placed on the dispatch queue
2. Task eventually shuffles to the top of the queue and starts running.
3. If the task voluntarily relinquishes control (due to some sort of SVC
call, etc) before the time slice expires, then the time slice duration gets
doubled and the priority is reduced by 50%.
4. Alternatively, if the time slice expires and the OS unilaterally wrests
control from the task, then the time slice duration gets halved and the
priority is bumped by 50%
5. Task is once more placed on the dispatch queue
6. etc...

I may have the actions of  (3) and (4) round the wrong way. I wouldn't be
at all surprised to be told I'm completely wrong. As I say, this is all
from a memory and I seem to have so few neurons left these days.

Sean

On Sun, 20 Oct 2019 at 14:02, Charles Mills  wrote:

> I just looked up "External Interruption" in the Principles. There are at
> least 9 possible causes.
>
> IIRC on the System 360 there was an eight-pin Molex connector available
> and a customer-provided box of some sort could trigger an external
> interrupt by pulling the appropriate pin to ground. See page 19 of
> http://www.bitsavers.org/pdf/ibm/360/systemSummary/GA22-6810-12_360sysSumJan74.pdf
> .
>
> IIRC MICR check sorters used this feature to generate their high-priority
> interrupts to the processor.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Brennan
> Sent: Saturday, October 19, 2019 7:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way for a task to give up the CPU and let other tasks
> run?
>
> Interesting, thanks!  So it generates an external interrupt.  I always
> thought that one was only for the external interrupt "key", but this
> page indicates CPU timer and some kind of CP-to-CP communication too:
>
>
> https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_interrupts.htm
>
> Ok... now back to my weekend work, like changing the oil in my truck.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Charles Mills]

I just looked up "External Interruption" in the Principles. There are at least 
9 possible causes.

IIRC on the System 360 there was an eight-pin Molex connector available and a 
customer-provided box of some sort could trigger an external interrupt by 
pulling the appropriate pin to ground. See page 19 of 
http://www.bitsavers.org/pdf/ibm/360/systemSummary/GA22-6810-12_360sysSumJan74.pdf
 . 

IIRC MICR check sorters used this feature to generate their high-priority 
interrupts to the processor.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Saturday, October 19, 2019 7:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Interesting, thanks!  So it generates an external interrupt.  I always 
thought that one was only for the external interrupt "key", but this 
page indicates CPU timer and some kind of CP-to-CP communication too:

https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_interrupts.htm

Ok... now back to my weekend work, like changing the oil in my truck.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

On 2019-10-18 11:20 PM, Seymour J Metz wrote:

ObUnclean Does Unix System Services implement its own spin locks or does it use 
MVS  services? Does any *ix have spin locks outside of the kernel


Unclean is subjective ;)

pthread_spin_lock()  - not implemented on z/OS

https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_spin_lock.html




--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Friday, October 18, 2019 1:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Typically, OS services like these and it's Unix equivalent sched_yield()
are used in spinlocks.

On 2019-10-18 1:20 AM, Mike Hochee wrote:

Yes exactly, that is part of what WLM is designed to do. In the real world most 
shops use WLM service classes and velocity goals to control things like CPU 
dispatching frequency. I'm sure there exist workloads which tend to defy the 
controls available in WLM, but I suspect they are quite rare. In all but those 
rare instances, I'd be inclined to steer clear coding something in a program 
for the purpose of getting it re-dispatched for some resource.

My nickels' worth.
Mike

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Thursday, October 17, 2019 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Caution! This message was sent from outside your organization.

Why? If you are waiting for something then you should use system services, 
e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something 
then why not let the WLM handle what it's designed to handle?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Thomas 
David Rivers 
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?

Does anyone happen to know the best way for a running task to give up running 
and let another task run?

But - this isn't "give up" as in ending the task, just giving up the CPU to 
allow another task to run and then returning to this task.

Sorta like "I'm done for the moment if something else would like to run".

 - Thanks -
  - Dave R. -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at 
http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Robert Prins]

On 2019-10-19 14:45, Charles Mills wrote:

Others have given you good replies. I've been thinking about your question
and thought I would summarize and re-phrase what has been said. You are not
very specific in what your situation is, so let me offer three possible
problem scenarios, each with its own solution.

I. "I am doing something that is going to require a whole lot of processing,
like computing pi to a million digits. It occurs to me that I have been
processing for quite some time. I would like to be polite and give others a
chance."


Oops, been there, did that, not for pi, but for "e", and I did it (in 1992), so 
before Nemiroff & Bonnell (See )


My PL/I program, using a far from optimal algorithm (a reverse Taylor series 
summation, only adding digits when required, feel free to ask for the initial 
source) just stopped after ten minutes, and I had to resubmit it again. A later 
version, for which I lost the source would run for a max of 6 hours elapsed 
time, but it also used the PL/I delay() builtin, and the PL/I multi-tasking 
facility to stop it via an (operator) reply. That one ran occasionally for a few 
hours on weekends. I no longer have any clue as to how much time the whole 
calculation took.


Needlessly to say management wasn't overly happy about the endeavour...

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

Maybe the OP just wants to implement sched_yield() for the Dignus 
compiler runtime?


On 2019-10-20 12:46 AM, Charles Mills wrote:

Thanks!

I suppose some encryption algorithm for which there was no hardware assist 
available might be a more practical real-world scenario.



An encryption algorithm may still be interrupted by the OS if it's 
accessing memory (page faults etc).


The only code I've seen that implements yield are synchronization 
routines. Consider a spin-lock which is spinning on a CS instruction. 
You need a mechanism to yield to other tasks otherwise
you will just hog the CPU until the time-slice expires. x86 has a pause 
instruction which gives the CPU a hint that a spinlock is in progress. 
Compilers implement the __mm_pause() intrinsic

function. I'm not sure if zArchitecture has an instruction like pause?

Most spinlock implementations I've seen have a backoff algorithm using 
these intrinsics with a counter until eventually taking the slow-path 
with a timer. This is explained well by a Google engineer
who is an expert in lock-free data strucutres 
http://www.1024cores.net/home/lock-free-algorithms/tricks/spinning.


You can see a real world example of how a spinlock is implemented using 
sched_yield() and a backoff algorithm in boost.


https://www.boost.org/doc/libs/1_38_0/boost/detail/spinlock_sync.hpp
https://www.boost.org/doc/libs/1_38_0/boost/detail/yield_k.hpp



Is there something in the dispatcher that is on a timer that ends up saying 
this task has gotten enough CPU and it's time to move to the next TCB?

In my way imperfect understanding, yes. I believe there is a hardware feature now wherein 
MVS can say "give me an interrupt when this CPU has run for nnn CPU 
microseconds" or something similar.

If not, then most operating systems have a concept of the time slice: we will 
let set a hardware timer for nnn real-time microseconds and when the timer goes 
off, re-evaluate our scheduling algorithm.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Saturday, October 19, 2019 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Great descriptions!  I was thinking of the PI calculation myself because
that's a case where you're doing real work, but the loop could be coded
with no I/O and no SVC calls (which would give up control).  Now here's
a case I thought about in the past:  Assuming I'm running such a PI
calculation (non-supervisor, interrupts enabled), what is it that
eventually interrupts my running code?  Of course there are previous I/O
completions from other tasks or CP's, but imagine (maybe on a
specialized system?) there's nothing much else going on.  Is there
something in the dispatcher that is on a timer that ends up saying this
task has gotten enough CPU and it's time to move to the next TCB?

On 10/19/2019 7:45 AM, Charles Mills wrote:

Others have given you good replies. I've been thinking about your question
and thought I would summarize and re-phrase what has been said. You are not
very specific in what your situation is, so let me offer three possible
problem scenarios, each with its own solution.

I. "I am doing something that is going to require a whole lot of processing,
like computing pi to a million digits. It occurs to me that I have been
processing for quite some time. I would like to be polite and give others a
chance."

Solution: Do nothing special. This is the magic of MVS and WLM. Assuming WLM
is set up properly, and you are in an appropriate WLM class, then when their
algorithms decide that someone else deserves to run, they will get to run,
and then after a while you will run again, all seamlessly and transparently,
with no effort on your part. (If that assumption is wrong, then you need to
fix that.)

II. "My code handles something that happens from time to time, like a
transaction coming in on the wire. There is no work to do at the moment but
there may be shortly."

Solutions: (a.) Look first at WAIT and POST. WAIT will let your task give up
the CPU until whatever process gives you work indicates that there is
something to do, with POST.

(b.) If you do not have control of the process that gives you work to do and
so cannot add a POST to it -- perhaps you are monitoring jobs in other
address spaces and watching for something to happen there -- then look at
STIMER WAIT. That will let you give up the CPU for a tenth of a second or
ten seconds or whatever is appropriate.

(c.) If there is plenty of work to do, but you need some resource that is
currently unavailable -- a file or a common buffer or something like that --
to be able to do it, then look at ENQ and DEQ. They will let you give up the
CPU until the process that is using the common resource relinquishes it.

In other words, there is no single magic "umm, I have nothing to do for a
little while; come back to me when I do" service 

Re: Best way for a task to give up the CPU and let other tasks run?

[Tom Brennan]

Interesting, thanks!  So it generates an external interrupt.  I always 
thought that one was only for the external interrupt "key", but this 
page indicates CPU timer and some kind of CP-to-CP communication too:


https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_interrupts.htm

Ok... now back to my weekend work, like changing the oil in my truck.

On 10/19/2019 3:54 PM, Charles Mills wrote:

Check out "CPU Timer" in the Principles of Operation.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, October 19, 2019 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Thanks!

I suppose some encryption algorithm for which there was no hardware assist 
available might be a more practical real-world scenario.


Is there something in the dispatcher that is on a timer that ends up saying 
this task has gotten enough CPU and it's time to move to the next TCB?


In my way imperfect understanding, yes. I believe there is a hardware feature now wherein 
MVS can say "give me an interrupt when this CPU has run for nnn CPU 
microseconds" or something similar.

If not, then most operating systems have a concept of the time slice: we will 
let set a hardware timer for nnn real-time microseconds and when the timer goes 
off, re-evaluate our scheduling algorithm.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Saturday, October 19, 2019 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Great descriptions!  I was thinking of the PI calculation myself because
that's a case where you're doing real work, but the loop could be coded
with no I/O and no SVC calls (which would give up control).  Now here's
a case I thought about in the past:  Assuming I'm running such a PI
calculation (non-supervisor, interrupts enabled), what is it that
eventually interrupts my running code?  Of course there are previous I/O
completions from other tasks or CP's, but imagine (maybe on a
specialized system?) there's nothing much else going on.  Is there
something in the dispatcher that is on a timer that ends up saying this
task has gotten enough CPU and it's time to move to the next TCB?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Charles Mills]

Check out "CPU Timer" in the Principles of Operation.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, October 19, 2019 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Thanks!

I suppose some encryption algorithm for which there was no hardware assist 
available might be a more practical real-world scenario.

> Is there something in the dispatcher that is on a timer that ends up saying 
> this task has gotten enough CPU and it's time to move to the next TCB?

In my way imperfect understanding, yes. I believe there is a hardware feature 
now wherein MVS can say "give me an interrupt when this CPU has run for nnn CPU 
microseconds" or something similar.

If not, then most operating systems have a concept of the time slice: we will 
let set a hardware timer for nnn real-time microseconds and when the timer goes 
off, re-evaluate our scheduling algorithm.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Saturday, October 19, 2019 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Great descriptions!  I was thinking of the PI calculation myself because 
that's a case where you're doing real work, but the loop could be coded 
with no I/O and no SVC calls (which would give up control).  Now here's 
a case I thought about in the past:  Assuming I'm running such a PI 
calculation (non-supervisor, interrupts enabled), what is it that 
eventually interrupts my running code?  Of course there are previous I/O 
completions from other tasks or CP's, but imagine (maybe on a 
specialized system?) there's nothing much else going on.  Is there 
something in the dispatcher that is on a timer that ends up saying this 
task has gotten enough CPU and it's time to move to the next TCB?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Charles Mills]

Thanks!

I suppose some encryption algorithm for which there was no hardware assist 
available might be a more practical real-world scenario.

> Is there something in the dispatcher that is on a timer that ends up saying 
> this task has gotten enough CPU and it's time to move to the next TCB?

In my way imperfect understanding, yes. I believe there is a hardware feature 
now wherein MVS can say "give me an interrupt when this CPU has run for nnn CPU 
microseconds" or something similar.

If not, then most operating systems have a concept of the time slice: we will 
let set a hardware timer for nnn real-time microseconds and when the timer goes 
off, re-evaluate our scheduling algorithm.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Saturday, October 19, 2019 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Great descriptions!  I was thinking of the PI calculation myself because 
that's a case where you're doing real work, but the loop could be coded 
with no I/O and no SVC calls (which would give up control).  Now here's 
a case I thought about in the past:  Assuming I'm running such a PI 
calculation (non-supervisor, interrupts enabled), what is it that 
eventually interrupts my running code?  Of course there are previous I/O 
completions from other tasks or CP's, but imagine (maybe on a 
specialized system?) there's nothing much else going on.  Is there 
something in the dispatcher that is on a timer that ends up saying this 
task has gotten enough CPU and it's time to move to the next TCB?

On 10/19/2019 7:45 AM, Charles Mills wrote:
> Others have given you good replies. I've been thinking about your question
> and thought I would summarize and re-phrase what has been said. You are not
> very specific in what your situation is, so let me offer three possible
> problem scenarios, each with its own solution.
> 
> I. "I am doing something that is going to require a whole lot of processing,
> like computing pi to a million digits. It occurs to me that I have been
> processing for quite some time. I would like to be polite and give others a
> chance."
> 
> Solution: Do nothing special. This is the magic of MVS and WLM. Assuming WLM
> is set up properly, and you are in an appropriate WLM class, then when their
> algorithms decide that someone else deserves to run, they will get to run,
> and then after a while you will run again, all seamlessly and transparently,
> with no effort on your part. (If that assumption is wrong, then you need to
> fix that.)
> 
> II. "My code handles something that happens from time to time, like a
> transaction coming in on the wire. There is no work to do at the moment but
> there may be shortly."
> 
> Solutions: (a.) Look first at WAIT and POST. WAIT will let your task give up
> the CPU until whatever process gives you work indicates that there is
> something to do, with POST.
> 
> (b.) If you do not have control of the process that gives you work to do and
> so cannot add a POST to it -- perhaps you are monitoring jobs in other
> address spaces and watching for something to happen there -- then look at
> STIMER WAIT. That will let you give up the CPU for a tenth of a second or
> ten seconds or whatever is appropriate.
> 
> (c.) If there is plenty of work to do, but you need some resource that is
> currently unavailable -- a file or a common buffer or something like that --
> to be able to do it, then look at ENQ and DEQ. They will let you give up the
> CPU until the process that is using the common resource relinquishes it.
> 
> In other words, there is no single magic "umm, I have nothing to do for a
> little while; come back to me when I do" service available in MVS without
> your specifying a little better what the condition is that will constitute
> "something to do."
>   
> III. "Everything you say is well and good, but my code is running in an MVS
> exit, or as an SRB, or holds locks, or something like that, which precludes
> the use of WAIT and similar services." I think this is not likely your
> situation but for completeness I will cover it.
> 
> Solution: yes, take a look at CALLDISP as others have suggested. It's not
> the right solution if I. or II. is your situation, but if III. applies, then
> yes, this is a possible answer to your question.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas David Rivers
> Sent: Thursday, October 17, 2019 8:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best way for a task to give up the CPU and let other tasks run?
> 
> Does anyone happen to know the best way for a running task
> to give up running and let another task run?
> 
> But - this isn't "give up" as in ending the task, just giving up
> the CPU to allow another task to run and then returning to this
> task.
> 
> Sorta 

Re: Best way for a task to give up the CPU and let other tasks run?

[Tom Brennan]

Great descriptions!  I was thinking of the PI calculation myself because 
that's a case where you're doing real work, but the loop could be coded 
with no I/O and no SVC calls (which would give up control).  Now here's 
a case I thought about in the past:  Assuming I'm running such a PI 
calculation (non-supervisor, interrupts enabled), what is it that 
eventually interrupts my running code?  Of course there are previous I/O 
completions from other tasks or CP's, but imagine (maybe on a 
specialized system?) there's nothing much else going on.  Is there 
something in the dispatcher that is on a timer that ends up saying this 
task has gotten enough CPU and it's time to move to the next TCB?


On 10/19/2019 7:45 AM, Charles Mills wrote:

Others have given you good replies. I've been thinking about your question
and thought I would summarize and re-phrase what has been said. You are not
very specific in what your situation is, so let me offer three possible
problem scenarios, each with its own solution.

I. "I am doing something that is going to require a whole lot of processing,
like computing pi to a million digits. It occurs to me that I have been
processing for quite some time. I would like to be polite and give others a
chance."

Solution: Do nothing special. This is the magic of MVS and WLM. Assuming WLM
is set up properly, and you are in an appropriate WLM class, then when their
algorithms decide that someone else deserves to run, they will get to run,
and then after a while you will run again, all seamlessly and transparently,
with no effort on your part. (If that assumption is wrong, then you need to
fix that.)

II. "My code handles something that happens from time to time, like a
transaction coming in on the wire. There is no work to do at the moment but
there may be shortly."

Solutions: (a.) Look first at WAIT and POST. WAIT will let your task give up
the CPU until whatever process gives you work indicates that there is
something to do, with POST.

(b.) If you do not have control of the process that gives you work to do and
so cannot add a POST to it -- perhaps you are monitoring jobs in other
address spaces and watching for something to happen there -- then look at
STIMER WAIT. That will let you give up the CPU for a tenth of a second or
ten seconds or whatever is appropriate.

(c.) If there is plenty of work to do, but you need some resource that is
currently unavailable -- a file or a common buffer or something like that --
to be able to do it, then look at ENQ and DEQ. They will let you give up the
CPU until the process that is using the common resource relinquishes it.

In other words, there is no single magic "umm, I have nothing to do for a
little while; come back to me when I do" service available in MVS without
your specifying a little better what the condition is that will constitute
"something to do."

III. "Everything you say is well and good, but my code is running in an MVS
exit, or as an SRB, or holds locks, or something like that, which precludes
the use of WAIT and similar services." I think this is not likely your
situation but for completeness I will cover it.

Solution: yes, take a look at CALLDISP as others have suggested. It's not
the right solution if I. or II. is your situation, but if III. applies, then
yes, this is a possible answer to your question.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?

Does anyone happen to know the best way for a running task
to give up running and let another task run?

But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.

Sorta like "I'm done for the moment if something else would like to run".

- Thanks -
 - Dave R. -

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Paul Gilmartin]

On Sat, 19 Oct 2019 10:45:39 -0400, Charles Mills wrote:

>Others have given you good replies. I've been thinking about your question
>and thought I would summarize and re-phrase what has been said. You are not
>very specific in what your situation is, so let me offer three possible
>problem scenarios, each with its own solution.
>
>I. ... III. ...
>
I've worked for a customer of the OP, so, possibly, plausibly:

IV.  "I need a portable solution, equally applicable to other than MVS."

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Charles Mills]

Others have given you good replies. I've been thinking about your question
and thought I would summarize and re-phrase what has been said. You are not
very specific in what your situation is, so let me offer three possible
problem scenarios, each with its own solution.

I. "I am doing something that is going to require a whole lot of processing,
like computing pi to a million digits. It occurs to me that I have been
processing for quite some time. I would like to be polite and give others a
chance."

Solution: Do nothing special. This is the magic of MVS and WLM. Assuming WLM
is set up properly, and you are in an appropriate WLM class, then when their
algorithms decide that someone else deserves to run, they will get to run,
and then after a while you will run again, all seamlessly and transparently,
with no effort on your part. (If that assumption is wrong, then you need to
fix that.)

II. "My code handles something that happens from time to time, like a
transaction coming in on the wire. There is no work to do at the moment but
there may be shortly."

Solutions: (a.) Look first at WAIT and POST. WAIT will let your task give up
the CPU until whatever process gives you work indicates that there is
something to do, with POST.

(b.) If you do not have control of the process that gives you work to do and
so cannot add a POST to it -- perhaps you are monitoring jobs in other
address spaces and watching for something to happen there -- then look at
STIMER WAIT. That will let you give up the CPU for a tenth of a second or
ten seconds or whatever is appropriate.

(c.) If there is plenty of work to do, but you need some resource that is
currently unavailable -- a file or a common buffer or something like that --
to be able to do it, then look at ENQ and DEQ. They will let you give up the
CPU until the process that is using the common resource relinquishes it.

In other words, there is no single magic "umm, I have nothing to do for a
little while; come back to me when I do" service available in MVS without
your specifying a little better what the condition is that will constitute
"something to do."

III. "Everything you say is well and good, but my code is running in an MVS
exit, or as an SRB, or holds locks, or something like that, which precludes
the use of WAIT and similar services." I think this is not likely your
situation but for completeness I will cover it.

Solution: yes, take a look at CALLDISP as others have suggested. It's not
the right solution if I. or II. is your situation, but if III. applies, then
yes, this is a possible answer to your question.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?

Does anyone happen to know the best way for a running task
to give up running and let another task run?

But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.

Sorta like "I'm done for the moment if something else would like to run".

   - Thanks -
- Dave R. -

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Christopher Y. Blaicher]

You only get the CPU for a time slice, or until the next interrupt occurs, 
which is very often.  After each interrupt, the highest priority piece of work 
is dispatched.  If you are still at the top, you go next.  If not, you wait 
until you are at the top of the dispatch chain.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Matt Hogstrom
Sent: Friday, October 18, 2019 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

From a design perspective it would seem that your task is done and waiting for 
more work?  Generally I’d think you’d want to wait and have someone post that 
work is ready or an stimer to wait for a period of time.  

z/OS is unlike many operating systems where it will pre-empt running work and 
so the need to yield is not really necessary.  

Matt Hogstrom
PGP key 0F143BC1

> On Oct 18, 2019, at 14:02, Tony Harminc  wrote:
> 
> On Thu, 17 Oct 2019 at 08:54, Thomas David Rivers  wrote:
> 
>> Does anyone happen to know the best way for a running task to give up 
>> running and let another task run?
> 
>> Sorta like "I'm done for the moment if something else would like to run".
> 
> This sounds so wrong right from the start. Or rather, sounds like 
> something that you might do if you were running on a thermostat or the 
> controller for a microwave or something, i.e. some environment where 
> there aren't OS services to manage all this.
> 
> I'm very curious about what has led you to believe you need to do 
> this. Has the work to be done somehow changed in importance? If so, 
> how would you discover this fact on the fly?  Can you give a 
> real-world example of why you'd want to yield to someone else, rather 
> than have the Powers That Be manage CPU resources for you?
> 
> If you *do* somehow discover that your work has become less important, 
> you might consider calling WLM to tell *it* that this is the case, 
> i.e. by changing the service class the work is in.
> 
> Tony H.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Matt Hogstrom]

From a design perspective it would seem that your task is done and waiting for 
more work?  Generally I’d think you’d want to wait and have someone post that 
work is ready or an stimer to wait for a period of time.  

z/OS is unlike many operating systems where it will pre-empt running work and 
so the need to yield is not really necessary.  

Matt Hogstrom
PGP key 0F143BC1

> On Oct 18, 2019, at 14:02, Tony Harminc  wrote:
> 
> On Thu, 17 Oct 2019 at 08:54, Thomas David Rivers  wrote:
> 
>> Does anyone happen to know the best way for a running task
>> to give up running and let another task run?
> 
>> Sorta like "I'm done for the moment if something else would like to run".
> 
> This sounds so wrong right from the start. Or rather, sounds like
> something that you might do if you were running on a thermostat or the
> controller for a microwave or something, i.e. some environment where
> there aren't OS services to manage all this.
> 
> I'm very curious about what has led you to believe you need to do
> this. Has the work to be done somehow changed in importance? If so,
> how would you discover this fact on the fly?  Can you give a
> real-world example of why you'd want to yield to someone else, rather
> than have the Powers That Be manage CPU resources for you?
> 
> If you *do* somehow discover that your work has become less important,
> you might consider calling WLM to tell *it* that this is the case,
> i.e. by changing the service class the work is in.
> 
> Tony H.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Tony Harminc]

On Thu, 17 Oct 2019 at 08:54, Thomas David Rivers  wrote:

> Does anyone happen to know the best way for a running task
> to give up running and let another task run?

> Sorta like "I'm done for the moment if something else would like to run".

This sounds so wrong right from the start. Or rather, sounds like
something that you might do if you were running on a thermostat or the
controller for a microwave or something, i.e. some environment where
there aren't OS services to manage all this.

I'm very curious about what has led you to believe you need to do
this. Has the work to be done somehow changed in importance? If so,
how would you discover this fact on the fly?  Can you give a
real-world example of why you'd want to yield to someone else, rather
than have the Powers That Be manage CPU resources for you?

If you *do* somehow discover that your work has become less important,
you might consider calling WLM to tell *it* that this is the case,
i.e. by changing the service class the work is in.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Seymour J Metz]

ObUnclean Does Unix System Services implement its own spin locks or does it use 
MVS  services? Does any *ix have spin locks outside of the kernel?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Friday, October 18, 2019 1:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Typically, OS services like these and it's Unix equivalent sched_yield()
are used in spinlocks.

On 2019-10-18 1:20 AM, Mike Hochee wrote:
> Yes exactly, that is part of what WLM is designed to do. In the real world 
> most shops use WLM service classes and velocity goals to control things like 
> CPU dispatching frequency. I'm sure there exist workloads which tend to defy 
> the controls available in WLM, but I suspect they are quite rare. In all but 
> those rare instances, I'd be inclined to steer clear coding something in a 
> program for the purpose of getting it re-dispatched for some resource.
>
> My nickels' worth.
> Mike
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Seymour J Metz
> Sent: Thursday, October 17, 2019 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way for a task to give up the CPU and let other tasks run?
>
> Caution! This message was sent from outside your organization.
>
> Why? If you are waiting for something then you should use system services, 
> e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for 
> something then why not let the WLM handle what it's designed to handle?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Thomas David Rivers 
> Sent: Thursday, October 17, 2019 8:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best way for a task to give up the CPU and let other tasks run?
>
> Does anyone happen to know the best way for a running task to give up running 
> and let another task run?
>
> But - this isn't "give up" as in ending the task, just giving up the CPU to 
> allow another task to run and then returning to this task.
>
> Sorta like "I'm done for the moment if something else would like to run".
>
> - Thanks -
>  - Dave R. -
>
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at 
> http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

Typically, OS services like these and it's Unix equivalent sched_yield() 
are used in spinlocks.


On 2019-10-18 1:20 AM, Mike Hochee wrote:

Yes exactly, that is part of what WLM is designed to do. In the real world most 
shops use WLM service classes and velocity goals to control things like CPU 
dispatching frequency. I'm sure there exist workloads which tend to defy the 
controls available in WLM, but I suspect they are quite rare. In all but those 
rare instances, I'd be inclined to steer clear coding something in a program 
for the purpose of getting it re-dispatched for some resource.

My nickels' worth.
Mike

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Thursday, October 17, 2019 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Caution! This message was sent from outside your organization.

Why? If you are waiting for something then you should use system services, 
e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something 
then why not let the WLM handle what it's designed to handle?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Thomas 
David Rivers 
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?

Does anyone happen to know the best way for a running task to give up running 
and let another task run?

But - this isn't "give up" as in ending the task, just giving up the CPU to 
allow another task to run and then returning to this task.

Sorta like "I'm done for the moment if something else would like to run".

- Thanks -
 - Dave R. -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at 
http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Bernd Oppolzer]

STIMER WAIT for a small amount of time;

I did this some years ago, when I wanted to show to some students how some
parallel running subtasks wrote their messages not sequentially, but mixed;
but, as it turned out, every subtask did its complete work in one step,
once started, because it never returned the CPU.

When I added some STIMER WAITs to the processing of the (identical) 
subtasks,

the messages appeared in mixed order.

HTH, kind regards

Bernd


Am 17.10.2019 um 14:54 schrieb Thomas David Rivers:

Does anyone happen to know the best way for a running task
to give up running and let another task run?

But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.

Sorta like "I'm done for the moment if something else would like to run".

  - Thanks -
   - Dave R. -



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Ed Jaffe]

On 10/17/2019 10:31 AM, Thomas David Rivers wrote:


Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED?

What about just a regular un-AUTH'd program?


CALLDISP does not require privileged execution unless you specify 
BRANCH=YES. Unauthorized callers should specify BRANCH=NO.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[John McKown]

On Thu, Oct 17, 2019 at 12:31 PM Thomas David Rivers 
wrote:

> Don Poitras wrote:
>
> >CALLDISP
> >
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm
> >
> >
> >
> >
> Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED?
>
> What about just a regular un-AUTH'd program?
>

Doesn't look like it requires any special authorization

Environment
These are the requirements for the caller:

   - When BRANCH=NO
   Environmental factorRequirement
   Minimum authorization: None.
   Dispatchable unit mode: Task
   Cross memory mode: PASN=HASN=SASN
   AMODE: 24- or 31- or 64-bit
   ASC mode: Primary
   Interrupt status: Enabled for I/O and external interrupts
   Locks: No locks held
   Control parameters: None.





>
>- Dave R. -
>
> p.s. *Thanks* for the pointer...
>
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Mark Jacobs]

When BRANCH=NO
Environmental factorRequirement
Minimum authorization:  None.
Dispatchable unit mode: Task
Cross memory mode:  PASN=HASN=SASN
AMODE:  24- or 31- or 64-bit
ASC mode:   Primary
Interrupt status:   Enabled for I/O and external interrupts
Locks:  No locks held
Control parameters: None.


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Thursday, October 17, 2019 1:31 PM, Thomas David Rivers  
wrote:

> Don Poitras wrote:
>
> > CALLDISP
> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm
>
> Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED?
>
> What about just a regular un-AUTH'd program?
>
> -   Dave R. -
>
> p.s. Thanks for the pointer...
>
> --
> riv...@dignus.com Work: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
>
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Thomas David Rivers]

Don Poitras wrote:


CALLDISP

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm


 


Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED?

What about just a regular un-AUTH'd program?

  - Dave R. -

p.s. *Thanks* for the pointer...

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Mike Hochee]

Yes exactly, that is part of what WLM is designed to do. In the real world most 
shops use WLM service classes and velocity goals to control things like CPU 
dispatching frequency. I'm sure there exist workloads which tend to defy the 
controls available in WLM, but I suspect they are quite rare. In all but those 
rare instances, I'd be inclined to steer clear coding something in a program 
for the purpose of getting it re-dispatched for some resource.

My nickels' worth. 
Mike

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Thursday, October 17, 2019 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way for a task to give up the CPU and let other tasks run?

Caution! This message was sent from outside your organization.

Why? If you are waiting for something then you should use system services, 
e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something 
then why not let the WLM handle what it's designed to handle?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Thomas David Rivers 
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?

Does anyone happen to know the best way for a running task to give up running 
and let another task run?

But - this isn't "give up" as in ending the task, just giving up the CPU to 
allow another task to run and then returning to this task.

Sorta like "I'm done for the moment if something else would like to run".

   - Thanks -
- Dave R. -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at 
http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Seymour J Metz]

Why? If you are waiting for something then you should use system services, 
e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something 
then why not let the WLM handle what it's designed to handle?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Thomas David Rivers 
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?

Does anyone happen to know the best way for a running task
to give up running and let another task run?

But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.

Sorta like "I'm done for the moment if something else would like to run".

   - Thanks -
- Dave R. -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at 
http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Tom Marchant]

On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers  
wrote:

>Does anyone happen to know the best way for a running task
>to give up running and let another task run?
>
>But - this isn't "give up" as in ending the task, just giving up
>the CPU to allow another task to run and then returning to this
>task.
>
>Sorta like "I'm done for the moment if something else would like to run".

Is the task one that purely uses CPU? Perhaps looping, looking at a queue 
for something to do, without ever waiting for anything? If so, perhaps it 
should issue STIMER WAIT when it detects that it has nothing to do.

If, OTOH, it waits for an ECB to be posted, or an I/O to complete, or any of a 
number of other things, it is already relinquishing control.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[David Crayford]

That's awesome Don!

So that's how to implement sched_yield()?

On 2019-10-17 10:02 PM, Don Poitras wrote:

CALLDISP

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm

In article <066301d584f2$b397cdc0$1ac76940$@mcn.org> you wrote:

#1, MVS manages that sort of thing with its wisdom, right? If it thought
someone else should run, it would pre-empt you and give control to that
other task.
#2, any SVC (or PC?) type system service call will cause MVS to re-evaluate
who should be dispatched *I think*.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?
Does anyone happen to know the best way for a running task
to give up running and let another task run?
But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.
Sorta like "I'm done for the moment if something else would like to run".


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Vernooij, Kees (ITOP NM) - KLM]

"I'm done for the moment if something else would like to run"
That's not for the task to decide: the dispatcher, under control of WLM, 
decides whether you get the CPU or will be removed from it to allow another 
task to run. All based on WLM directions, which you can influence by selecting 
a Service Class with a certain Goal.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: 17 October, 2019 16:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way for a task to give up the CPU and let other tasks
> run?
> 
> On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers wrote:
> 
> >Does anyone happen to know the best way for a running task
> >to give up running and let another task run?
> >
> >But - this isn't "give up" as in ending the task, just giving up
> >the CPU to allow another task to run and then returning to this
> >task.
> >
> >Sorta like "I'm done for the moment if something else would like to run".
> >
> What does "for the moment" mean?  If your process has nothing
> more to do, it should just quit.  If it needs to wait for an event,
> there are various programming interfaces for such things.
> 
> See also setpriority().
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Paul Gilmartin]

On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers wrote:

>Does anyone happen to know the best way for a running task
>to give up running and let another task run?
>
>But - this isn't "give up" as in ending the task, just giving up
>the CPU to allow another task to run and then returning to this
>task.
>
>Sorta like "I'm done for the moment if something else would like to run".
> 
What does "for the moment" mean?  If your process has nothing
more to do, it should just quit.  If it needs to wait for an event,
there are various programming interfaces for such things.

See also setpriority().

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Don Poitras]

CALLDISP

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm

In article <066301d584f2$b397cdc0$1ac76940$@mcn.org> you wrote:
> #1, MVS manages that sort of thing with its wisdom, right? If it thought
> someone else should run, it would pre-empt you and give control to that
> other task.
> #2, any SVC (or PC?) type system service call will cause MVS to re-evaluate
> who should be dispatched *I think*.
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas David Rivers
> Sent: Thursday, October 17, 2019 8:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best way for a task to give up the CPU and let other tasks run?
> Does anyone happen to know the best way for a running task
> to give up running and let another task run?

> But - this isn't "give up" as in ending the task, just giving up
> the CPU to allow another task to run and then returning to this
> task.
> Sorta like "I'm done for the moment if something else would like to run".

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Charles Mills]

#1, MVS manages that sort of thing with its wisdom, right? If it thought
someone else should run, it would pre-empt you and give control to that
other task.

#2, any SVC (or PC?) type system service call will cause MVS to re-evaluate
who should be dispatched *I think*.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Thursday, October 17, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way for a task to give up the CPU and let other tasks run?

Does anyone happen to know the best way for a running task
to give up running and let another task run?

But - this isn't "give up" as in ending the task, just giving up
the CPU to allow another task to run and then returning to this
task.

Sorta like "I'm done for the moment if something else would like to run".

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way for a task to give up the CPU and let other tasks run?

[Vernooij, Kees (ITOP NM) - KLM]

WLM: give the job a Serice Class with Importance=5 and a Velocity=1. It will be 
thankful for each CPU second that is left unused by all other tasks in the 
system.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas David Rivers
> Sent: 17 October, 2019 14:54
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best way for a task to give up the CPU and let other tasks run?
> 
> Does anyone happen to know the best way for a running task
> to give up running and let another task run?
> 
> But - this isn't "give up" as in ending the task, just giving up
> the CPU to allow another task to run and then returning to this
> task.
> 
> Sorta like "I'm done for the moment if something else would like to run".
> 
>- Thanks -
> - Dave R. -
> 
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN