Network Application Platform (NAP) Applications

The existing behaviour for NAP glb.unique is that its setting is based on the transaction 'type' flag as sent from NAP.

If this flag (na_no_tr_info) is zero, then AB Suite sets Glb.Unique to the next available Unique value otherwise it explicitly set the Glb.Unique to 0.

The new behaviour for NAP glb.unique (retain prior glb.unique value when na_no_tr_info is > 0) is enabled by setting (WFL MODIFYing) the SW2 flag on <sys>/NAP_ENVIRONMENT. If SW2 is not set, then the current (existing) behavior will be retained. If active, the system must be restarted after performing the WFL MODIFY.

For situations where there are large number of NAPTP’s active (50+), then during a hotswap following a generate, there is a possibility of the calls being lost. This has been addressed for most situations but should the issue occur in your NAP environment then use the <lincsupport mix> AX NAP_DELAY nn to set a larger delay time between closing down NAP updates to stop calls being lost (minimum and default is 1 second).

The default behaviour for NAP applications is that most of the runtime faults will be reported (a line 25 message and a Sumlog entry) but no dumps will be taken. This is done to ensure minimum performance impact on the NAP processing in the event of runtime failure. However, there might be situations where a dump is required to facilitate the analysis of the runtime failure cause. In such cases, there are two options available: