It should also be noted that the zap approach changes the address space limits for all address spaces on the system, not just a select few. The new program interface enables the change to a single (ostensibly high ENQ using) address space.
Consider DB2, which wants to open up tens (if not hundreds) of thousands of datasets. Each dataset allocation accounts for a single SYSDSN ENQ, each OPEN accounts for a one, two, three...(?) of SYSVSAM ENQs. It doesn't take long to exceed 250K ENQs. Under the zap approach, _any_ address space would be able to ENQ up to the new limit. Each ENQ uses some storage in the GRS address space, some of which is below the bar (not below the line). As systems become larger, the number of concurrent ENQs in a single system continues to increase (think of consolidating multiple DB2 subsytems on a single z/OS image). There is a reachable limit of concurrent ENQs in the _system_. There is no absolute number, as the size of some of the control blocks is variable. The limit is imposed mostly as a safety precaution, to protect the system from a runaway user. As John stated, other actions are being taken to raise the system wide limit, such as moving some control blocks above the bar, leaving more room below the bar for ENQ storage. Some web references: http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_Sea ttle/S2855SF021609.pdf - see page 6-9 http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_Sea ttle/S2884NM113946.pdf - see page 36-39 Scott Fagen z/OS Core Technology Design IBM Poughkeepsie ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
