Enterprise Cobol - Using coprocessors as independent tools

Hi, since there have been no updates, we shall go ahead and cancel this RFE. Thanks.

May we know if you got a chance to review our April 29th, 2020 update?

We shall keep this RFE open till June 17th, 2020 after which we shall close it if no response by then. Thanks.

May I know if you had a chance to review our previous update?

From a compiler point of view, we do not see an easy/clean solution for this RFE.
We cannot guarantee that the DBRM file for the BIND won't change.

As a result, this is being rejected from a compiler point of view.

Please let us know if you would like us to pass this to the DB2 team to see if any alternative method can be used.

Thanks.

Thank you for the additional information. We are reviewing your response and will update you shortly.

> You should do 2 builds, why not re-BIND for the second compile? Is this a problem?

Yes this is a problem :
- normal production machines are Z14
- disaster recovery machines are Z13

For benefit of Z14 in normal conditions and for compatibility with Z13 in recovery conditions we should compile twice (two loadmodule)... and in case of use of Db2 coprocessor we should bind twice (two dbrms, two packages, two collections, one plan) because recovery images come from production capture.
At runtime, Db2 must select the right package corresponding with the Z14 or Z13 lodmodule.
Two more packages in Db2 catalog, two more dbrms (two PDS), more administrative tasks (twice) for Db2 administrator.

Hi,

We have a few comments related to your description. Our responses are marked with ">"

The use of DB2 and CICS preprocessors is deprecated in favor of the coprocessors built into the Cobol compiler.
>Separate Db2 precompiler and separate CICS translator are still fully supported

We would like to be able to use the coprocessors as independent utilities, ie to transform the EXEC commands into Cobol instructions without triggering a Cobol compilation.
> You could use SQL and NOCOMPILE options with MDECK to get transformed source in SYSMDECK

For this, the option MDECK(NOCOMPILE), associated with the SQL or CICS options, should produce a Cobol source with translation of the EXEC commands to Cobol statements as the preprocessors DB2 and CICS would have done.
> We provide MDECK with NOCOMPILE today

No new DBRM built at second compilation : same DBRM used for BIND of first and second compilations ; no need to re BIND at previous stages.
> You should do 2 builds, why not re-BIND for the second compile? Is this a problem?

If the program contains SQL statements, recompiling with SQL option will produce a new DBRM with a new timestamp.
In a build chain, with several stages of environments and concatenation of loadlibs, (moving programs from one loadlib to another during promotions, like SCLM or CA Endevor), this forces to redo the BIND PACKAGE of the upstream environments, then that functionally the DBRM is identical (the EXEC SQL commands are not modified between the compilations).
> The DBRM would not be identical, we do not understand why BIND PACKAGE is not part of your normal application build process, and this build process should be done twice for the first time that a program is compiled with COBOL V6

This RFE is being investigated further.