Actually, I don't know how you can prevent giving up the processor
unless you mask off all interrupts and maintain a dispatching priority
of 255 and even that would probably only work n a uni-processor LPAR.
Even the hard loop in the example doesn't prevent preemption by higher
priority work units, given that interrupts are allowed on one or more
CPUs in the LPAR.
There was once a "system must complete" state that might have been able
to do this, but I'm not sure it is supported any more. I seem to recall
that even that status only guaranteed that an interrupted work unit
would regain control after the interrupt was fielded, so interrupt
processing still prevents the task from constantly using the CPU.
Why would you want to do this and defeat the function of the operating
system?
Mike Myers
Mentor Services Corp.
On 9/12/2010 1:04 PM, Stan Weyman wrote:
<< WTOR 'WAIT AND DON'T GIVE CONTROL TO ANOTHER TASK.',REPLY,1,RESPECB
So instead of doing a WAIT ECB=RESPECB AFTER THE WTOR
HARDLOOP DS 0H
TM RESBECB,X'40'
BNO HARDLOOP
Can you imagine if everyone did this to get around giving up control of the
processor<sigh>
This is not a solution. It might work, but not a solution. Can you
describe more what you are trying to do??
Stan
Stan Weyman
Senior Software Engineer
stan.wey...@emc.com
EMC² (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
michealbutz
Sent: Sunday, September 12, 2010 1:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Issuing WTOR SVC In Multitask Environment
WTOR 'WAIT AND DON'T GIVE CONTROL TO ANOTHER TASK.',REPLY,1,RESPECB
So instead of doing a WAIT ECB=RESPECB AFTER THE WTOR
HARDLOOP DS 0H
TM RESBECB,X'40'
BNO HARDLOOP
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Gerhard
Postpischil
Sent: Sunday, September 12, 2010 1:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Issuing WTOR SVC In Multitask Environment
On 9/12/2010 12:56 AM, michealbutz wrote:
In a multitask environment this would cause the dispatcher to
give control to another task while waiting for a operator
reply
Did somebody rewrite the Operating System while I wasn't
looking? When you issue a valid WTOR, control is returned to
your task (subject to normal dispatching considerations). The
communications task will asynchronously issue the WTOR request
to the appropriate console.
Is there some way of making sure that the dispatcher doesn't
give up control of the task that issued the WTOR and wait for
a reply
No, but I think you're confused. Nobody is forcing you to wait
for a reply unless your program has a WAIT SVC. If you want to
keep running, don't WAIT.
But if your intention is to keep running normally, with a WTOR
response being optional, you should look at the MODIFY facility,
that allows the operators to issue a command to your task
without tying up a response number.
Gerhard Postpischil
Bradford, VT
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
