Provide ability to set and enforce a limit to the number of concurrent LP ECBs

There are tuning (core allocation and shutdown threshold level) implications to running large numbers of LP ECBs. A customer really needs to determine a max number of LP ECBs they will allow to run concurrently. If tuning values are set based on a max number of LP ECBs there needs to be a way to enforce this limit. Key requirements for the support requested include
1) The ability to define the max number of LP ECBs allowed to run concurrently so this value is accessible at runtime.
2) A means of enforcing this limit, either through system-level enforcement or through coded APIs to check whether the max LP ECB value has been reached. In the latter case, it is understood that "enforcement" is reliant on API callers not spinning up more LP ECBs if API call indicated the max number of LP ECBs had already been reached.

LP support allows temporary suppression of the LP status of an ECB in order to e.g. avoid RHT delays because the LP ECB holds a record required by non-LP ECBs. The number of LP ECBs in the system should include any LP ECBs whose LP attribute has been temporarily suspended by system level actions taken to avoid such problems.

Ideally, the current number of LP ECBs assessed by this new support should include the number of "pending create LP ECBs" i.e. the count of create requests made by LP ECBs which pass their LP attribute to their children. Including pending LP creates in the count of LP ECBs is inline with LODIC's assessment of "in-use ECBs".


Other thoughts/comments around possible ways to provide this support:
1) System-level enforcement at create time would avoid reliance on coding new APIs but raises significant questions about what action the system should take if there are already the max number of allowed LP ECBs in the system. The system could treat this condition as being the same as not enough XWBs to service a create and back up the NSI in the PSW, but that may not be desirable in all cases, e.g. for ECBs being created to provide system-level support functions such as RELFC processing.

2) If an API is provided, we would ask that IBM utilities that ran as LP issued this API to ensure they also adhered to max LP ECB limits.

3) There is a question about whether enforcement *should* apply to the case where an ECB has already been created as normal priority and then issues the tpf_eastec API to set the LP attribute. In that case it may not be desirable for any system level enforcement to force the ECB to give up control if we already have the max LP ECBs allowed and only allow it to complete when the max LP ECB count will not be exceeded. The point of the request for the support is to stop us depleting ECBs by spinning up more LP ECBs than we have tuned for. If we have already spun up an ECB as non LP there is little benefit then stopping it running just because it now want to become an LP ECB.