Foreign Action Block -

[Andrew Murphy]

First time psoter here.

We use Coolgen 8.4, with the application deployed on IBM CICS/DB2....with some elements of batch processing (data loading).  The application is 30 years old (we were one of the early adopters of IEF).  Our Coolgen model/application is composed of 2x Business Systems - 1x online & 1x batch,
We have a modest number of shared action blocks, two of which are re-shared across the 2 business systems....and  appear in the 2nd business sytem as a "foreign Action Block".  Behind the scenes the generated code across the entire application is COBOL.

In theory we can generate the program code for the shared action blocks from either business system.  And in theory the COBOL code should be identical (excpt for genration timestamps details).  However we have found that the online business system version of the COBOL contains the following code narrative
* FOLLOWING LINE ADDED POST-GENERATION
* TO RE-INITIALIZE FOR DYNAMIC CALLS
MOVE ZERO TO SQL-INIT-FLAG.

whereas the same Action Block generated from the batch business system does not have this code segment.  The resultant load modules differ in size....which to date has not been an issue....because the resultant load module has been "static linked"...but now we are obliged by the company IT strategy to move to "dynamic linking" and I have a concern that this may cause a problem.

Has any one come across this...and could it be a problem?

[DEE OTT]

We are using Gen 8.6 and have a ton of “dual” action blocks.  That is what we call the action blocks that are used by both batch and online.  We started with dual action blocks way back when it was still called IEF though so in this case version probably doesn’t matter too much.  We use dynamic linking.  As a rule we only ever generate them from the “owning” business system. Our “owning” business system is online for some and batch for others.  No standard as to what owns a dual action block.  It is just whatever business system needed it first.  Then we use a “link only” option (our own encyclopedia customization) to do the link from the foreign business system and we submit a bind for the “foreign” collection outside of Gen (we have a batch collection and an online collection).  Way back in the day, I don’t know if it is still true or not, if you generated and installed from the foreign business system it didn’t do the compile.  You could force it but we just added the link option and made the rule about always generating from the “owning” business system.  We have been doing it that way ever since.  We have not noticed any issues with our duals.

Here is an explanation of our Customization:

Add Link Only Option for Dynamically Linked Objects

This allows the developer to request that only a specific action block within a procedure be link-edited instead of all action blocks within the procedure step.  Without this option a lot of CPU and developer time is wasted link-editing modules that have not been recompiled.  It also places unchanged programs in the load library, which reduces the PMA’s ability to verify moves to production, and will cause timestamp errors in development over time.

Gen will automatically compile and link any dynamically linked object that was generated if an installation is requested.  The Link Only option will be used for linking a dual action block in the foreign business system. 

The ‘L’ option only works with foreground processing.  It cannot be used with background processing because the modification for background processing has not been made.

Member Modified:	CEHBPNL0(TILMPRC2)
Member Purpose:	Displays The Expanded Load Module Component Table for a batch load module
Modification:	Add “L=Link Only” text to the body of the panel and add ‘L’ to the list of valid pitons in the verify statement.

 

Member Modified:	CEHBPNL0(TILMPROC)
Member Purpose:	Displays The Expanded Load Module Component Table for an online load module
Modification:	Add “L=Link Only” text to the body of the panel and add ‘L’ to the list of valid pitons in the verify statement.

 

Member Modified:	CEHBCLS0(TICCGENE)
Member Purpose:	Displays The Expanded Load Module Component Table “Ticstpl” and Process/Validate the selections made against it.

Modification:

Within the RESLOOP section of the code where it checks each object and the action requested, if the action is an L and the action block is not external, set all the installation parameters and execute  %TICINST.  Two shared variables were created to accomplish this.  They are AMFMLNK and AMFMLOD.  AMFMLNK is a flag.  When it is set to ‘Y’, a link only was requested for the action block.  AMFMLOD is the member name of the action block that the link only was requested for.

 

Member Modified:	CEHBCLS0(TICCMLK)
Member Purpose:	Clist that does the VS COBOL II Compile and Link of Advantage Gen generated code
Modification:	At the very beginning of the clist, get the AMFMLNK and AMFMLOD variables.  If the link is Y and the member that is being processed is not the same as the AMFMLOD, then skip the installation.

Dee

[Clay Rabun]

Andrew,

Generated source members that contain SQL and are called dynamically have the "MOVE ZERO TO SQL-INIT-FLAG" line added by a post-generation edit macro. This line is necessary to prevent potential problems if the member is called more than once at execution time.

As Dee suggested, I would also recommend that you generate/build any Foreign Action Blocks in the owning Business System. This is the best way to make sure that the edit macro gets invoked to add this line of code and each Action Block gets built correctly.

Also, you will need to be aware of differences you may experience when switching from statically linked Action Blocks to dynamically linked Action Blocks. When your shared Action Blocks were statically linked, the correct DB2 Attach module would get pulled in whenever Gen linked your application load modules. For example, your CICS applications would include DSNCLI and your Batch applications would include DSNELI.

Now that you are going to be using dynamically linked Action Blocks, you are going to need two different executable versions of each shared Action Block - one for your CICS applications and one for your Batch applications. To accomplish this, you will need to enter another dataset name in the "1. Specify internal libraries.....Exec batch dynam AB library" field. Then when you build your dynamically called Action Blocks, Gen will create two Action Block DLLs. The DLL in the "1. Specify internal libraries.....Executable Load modules" dataset will include DSNCLI and this DLL should be deployed to your CICS environment. The DLL in the "1. Specify internal libraries.....Exec batch dynam AB library" dataset will include DSNELI and this DLL should be deployed to your Batch environment.

Alternatively, if you are on Gen 8.6, you could take advantage of Gen's DSNULI support. On the "Specify Target Environment" panel, if you enter "YES" for the "Support for DSNULI" field, then Gen will use the DSNULI DB2 Attach module and you will only need to have one Action Block DLL that can be used in both your CICS and Batch environments. To use this option, you will need to enter another dataset name in the "1. Specify internal libraries.....DSNULI dynam AB library" field. Please note that Gen does not support the DSNULI option at this time for IMS environments or the TSO Test Facility.

Regards,
Clay