AFAIK, there's nothing available within z/OS itself to cancel an 
individual enclave, although I certainly have wanted that capability 
sometimes.  This makes sense when you think about what enclaves 
are: they're really sub-tasks from an address space more so than 
being their own address space.  So the correct answer is that to get 
rid of an enclave, you have to cancel the unit of work from the task 
that owns the enclave, in this case, apparently DB2.

You can change the service class of an active enclave, maybe to keep it 
from consuming resources.  But a couple of caveats: 

1) Beware dependent enclaves as changing the service class of those 
will effect the owning address space.  I've seen CICS create 
dependent enclaves and you don't want to touch those.  

2) For DDF work that's running on the zIIP, if you're thinking to change 
the service class to one with a Resource Group cap to keep it from 
consuming zIIP resources, that probably won't work well as work on 
specialty engines don't accumulate SUs towards RG caps.  At least that 
what I've been told, and that's what I've generally seen.  

Finally, since this is DB2, we recently ran into a problem where QMF 
DDF threads wouldn't go away: they couldn't be cancelled from DB2 
and seemed to be stuck looping.  Turns out there was a bug in one of 
our DB2 monitoring products (from IBM, no less) that was keeping 
them from going away.  This was somewhat problematic because of 
point #2 above: they thread was consuming zIIP resources that other 
threads could use.  To try to resolve this (at least partially) I put it in 
my SC with a RG cap of 1 SU, varied the zIIP off line to get it on the 
GCP, then put the zIIP back online.  This seemed to slow it down, 
although I'm still not sure why it worked as well as it did: I expected it 
to bounce back to the zIIP and run away again in short order.  While it 
did bounce back to the zIIP, it consumed at a much lower rate than 
before.  Again, I don't have an explanation, I only relate the 
experience in case you're stuck in a similar situation, maybe it might be 
something to try.

----------------------------------------------------------------------
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

Reply via email to