When an External Action Block has its associated Dynamically Linked Packaging property set to Yes, migrating to CA Gen 8.5 requires the EAB to be recompiled and reinstalled as a DLL. If the EAB dynamically calls other user programs, those user programs must also be built as DLLs.
When an External Action Block has its associated Dynamically Linked Packaging property set to Compatibility, the option Process modules marked for Compatibility determines if the EAB must be rebuilt as a z/OS non-DLL load module or should remain as built by the releases of AllFusion Gen before release 7. In either case, if the EAB dynamically calls other user programs, those user programs must also be non-DLLs.
How an External Action Block that has its associated Dynamically Linked Packaging property set to NO, thus is statically linked into the calling application, is compiled depends on the type of application that calls it. When the calling application is marked for Compatibility the EAB must be built using the NODLL compiler option and be placed in a library in the Static External Action Block panel. When the calling application is not marked for Compatibility the EAB must be built using the DLL compiler option and be placed in a library in the External Action Block panel. When called by both application types, two copies of the EAB must be built and each placed in the appropriate library.
In CA Gen 8.5 if an EAB uses a CICS XCTL or CICS START API command to flow to another CICS transaction (thus not returning), that EAB must delete a TSQ before it executes the XCTl or START.
If the application executing the EAB was built by CA Gen 8.x, the TSQ is named MMCB<APPLID>#### (where #### is the packed CICS Taskid).
If the application executing the EAB was built by CA Gen 7.6 or earlier release, the TSQ name is AMCB<APPLID>####.
For more information about EABs, see the chapter "Implementing External Action Blocks."
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|