The syntax for this command is as follows:

BINDLIMIT n
BINDLIMIT n *
BINDLIMIT n #N

Background

The AB Suite MCP Runtime relies on dynamic stack building during its transaction processing. As each ispec, method library, or user library is first invoked, the associated Stub is added to the code library execution stack.

During the deployment of an application, BLD ensures that the generated code libraries hold as many ispecs and libraries (Stubs) as possible, within the system limits of the code library codefile size and Binder limits. Thus, the number of code libraries required is minimized and the runtime efficiency is maximized by having a smaller application foot print.

However, the consequence of maximizing the code library size is that the code library has the potential to exceed the MCP defined stack limit at runtime. To prevent this, the Runtime will detect an imminent stack limit issue (the stack size is approaching the MCP 62k system limit) and invoke an implicit hotswap of the offending code library (to minimize overhead, only the offending code library is involved in the implicit hotswap).

To prevent this situation from becoming a routine occurrence for an application, the following heuristic approach is used to optimize the code library size.

When the runtime detects that the stack is approaching the stack limit, it will persist the current size of the code library, is known as the Stub limit, expressed in number of Stubs added to the stack (the stubs of ispecs, method libraries, and user libraries), in addition to performing the hotswap. On the next Build or Rebuild of the application, the number of Stubs bound into each code library will be reduced from the MCP RT default value (600), or the current value, to the new Stub limit value that was saved at the last hotswap.

If the Stub limit value has changed after the last build, the BLD utility will perform a full rebind of all code libraries using the new Stub limit value. Note that only those ispecs or methods that are changed and uploaded from Developer will be compiled. For all other ispecs or methods, the rebind will use the existing codefiles, so that the rebind overhead is very light. (This applies to applications that are deployed by a build from Developer. It does not apply to applications deployed by Runtime Transfer.)

After the build has performed a full rebind of the all code libraries due to a change in the Stub limit value, the application will be marked as rebind done, so that a subsequent deployment will not force a full rebind again until either a REBUILD is requested or another occurrence of an imminent stack limit issue creates a new lower Stub limit value.

The BINDLIMIT command provides manual management of the persisted Stub limit for system index N by allowing the interrogation, default restoration (*), or modification of the code library Stub limit (#N), where N, is between 200 and 600.

If your application is deployed using MCP Runtime Transfer, check the SUMLOGs for the following display:

"Implicit CUTOVER for Code Library N - Stack Size: SS , Prior Value: PV (Limit L) - Stub Count: 
SC [Implicit CUTOVER for Code Library N - Stack Size: SS , Prior Value: PV (Limit L) - Stub Count: SC [

For the system build of the Source application of the transfer, set BINDLIMIT to the Stub Count value.

Changing the BINDLIMIT value, either by restoring to the default or supplying a new value, will cause a Rebind on the next deployment of this system.

The BINDLIMIT value will remain in place until it is updated here or a new and lower value is detected and persisted during the execution of the application.