Contacting ESP is the right approach. We cap the number of ENQs any one space can obtain. This limit is in place to prevent a "runaway" program from utilizing all the storage in the GRS address space. This limit is customizable either at the address space level via the ISGADMIN API, or at the system level via the SETGRS ENQMAXU command.
The 16K limit is not a "table," it is strictly the limit that a single (unauthorized) space is allowed to obtain. If ESP were to reach that limit, further ENQs from that address space would fail, but the rest of the system would continue to function normally. The GRS EQDQ Monitor (MVS Planning: Global Resource Serialization, Chapter 3) can be used to see the ENQ activity. A filter on the jobname could be used to focus in on the ESP program's activity. Chris Brooker GRS Level 3 Team Lead On Thu, 4 Jun 2009 08:08:23 -0500, J Ellis <jerry.el...@libertymutual.com> wrote: >We have considered raising it, however we would really like to figure out >whats going on and if it is in fact ESP (we are contacting them). For a >single A/S to be using more than 80% of a 16K table for enq/deq seems a bit >excessive. We are concerned about what will happen when we roll this into >our main 5 lpar plex > >---------------------------------------------------------------------- >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
