NOTICE: Significant community changes coming soon
The header menu and the home page on our community will be changing soon. Get more information HERE.
Absent Member.
Absent Member.

Managed DLL, two classes with EXEC SQL, only 1 bnd - possible?


I have a question regarding Managed Cobol DLLs with more than 1 classes and EXEC SQL Statements.

At the moment, if I have a project, with 2 Classes, TestA and TestB, and both have EXEC SQL statements in them, I would get 2 bnd files, each named after the class (TestA.bnd and TestB.bnd). Is it somehow possible to create a merged bnd file for these 2 classes by setting some db2 precompiler settings?

Up to now I was not able to achieve that. I don't even know if that is possible at all, as I haven't found anything in the documenation about such topics.

Thanks for you help, best regards Thomas

1 Reply
Micro Focus Expert
Micro Focus Expert

Your question states that you are creating managed COBOL .dlls yet you are using the DB2 ECM to precompile your embedded statements.

Currently there is no managed code version of the DB2 ECM so I am assuming that you are actually creating native Windows .dlls instead of managed .dlls, is that correct?

Using the DB2 directive with the BIND option will always create one bind file per source program that is precompiled. That is because the precompiler works at the source code level and knows nothing about which programs are packaged into a particular .dll or executable.

I don't believe that there is a workaround for this but perhaps someone with more DB2 experience could chime in here with a definitive answer?


The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.