Gen EDGE

 View Only
  • 1.  RI DLL

    Posted Aug 11, 2022 08:04 AM
    2nd question from a first time poster.

    We use CoolGen 8.4, with an application deployed on IBM CICS/DB2.  We have (Cascade delete/update) RI triggers, which upto now were "static linked".  We are now moving to "Dynamic linked" all code.  This change has caused us to have to adjust our load libraries slightly.  Coolgen insists on unique libray names.

    In the mainframe toolset, we have the options
    2.  Specify RI Trigger Libraries.....Compiled load modules . . .
    and
    4.  Specify RI Trigger Libraries for Dynamic Link....Executable Load modules . . . 

    The RI triggers all end up in 1 file in each library (effictively a DLL?).  My question is which library do I use to deploy to production?  The same file exists in both libraries, with the same load module size....but using a file-compare tool the internal content of the file in 2 is very slightly different from the file in 4.  I'm leaning towards the file in 4, but not 100% sure.

    Any advice available please?​​


  • 2.  RE: RI DLL

    Broadcom Employee
    Posted Aug 12, 2022 07:06 PM
    Andrew,

    On the "Specify RI Trigger Target Environment Parameters" panel, if you enter "YES" for the "Dynamically Link RI Triggers" option, then all the individual RI Triggers NCAL load modules will be linked into a single DLL named CASCADE (or whatever is entered in the "RI Trigger Name (Cascade)" field).  I would expect the "2. Specify RI Trigger Construction Libraries.....Compiled load modules" dataset to contain all the individual RI Trigger NCAL load modules (usually named E* and F*).  And I would expect the "4. Specify RI Trigger Dynamic Link Libraries.....Executable Load modules" dataset to contain one DLL named CASCADE.  So it would be the CASCADE DLL in 4 that should be deployed to your production CICS environment, assuming you entered "CICS" in the "TP Monitor" field.

    If this is not what you are seeing, then you may want to open a Support ticket so we can assist you further.

    However, I should also point out another difference you will experience when switching from statically linked RI Triggers to dynamically linked RI Triggers. When you were statically linking your RI Triggers, 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 RI Triggers, you are going to need two different CASCADE DLLs - one for your CICS applications and one for your Batch applications. To accomplish this, you will need to enter another dataset name in the "4. Specify RI Trigger Dynamic Link Libraries.....Executable Batch Load modules" field. Then when you build your RI Triggers, Gen will create two CASCADE DLLs. The CASCADE DLL in the "4. Specify RI Trigger Dynamic Link Libraries.....Executable Load modules" dataset will include DSNCLI and this DLL should be deployed to your CICS environment. The CASCADE DLL in the "4. Specify RI Trigger Dynamic Link Libraries.....Executable Batch Load modules" 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 RI Trigger Target Environment Parameters" 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 CASCADE 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 "4. Specify RI Trigger Dynamic Link Libraries.....Exec DSNULI Load modules" field. Please note that Gen does not support the DSNULI option at this time for IMS environments or the TSO Test Facility.

    Regards,
    Clay