Hi 

is that consistency token pattern between load and dbrm is same in cobol 6.2. we usually see it as revers of fiurst 8 digits in 4.2.
please advise.

------------------------------
priyadarasini Esvar
------------------------------

This is a duplicate post to this one.

------------------------------
Linda Chui
Compilation Technology & Enterprise Products
IBM Canada
------------------------------

I am unclear if the token is causing a Bind or run-time problem, or you simply are bothered by the difference?

Let me suggest you might switch to use the SQL CoProcessor built into the compiler.  If you use CICS, you can also use the built-in CICS Translator.

In addition to not having to maintain separate products, messages will be listed in-line with the COBOL messages, and you will  get all the new COBOL language features which are not always handled properly by the external processes.

------------------------------
Jon Butler
------------------------------

Hi Jon,

People have been using the consistency token embedded in the executable and the DBRM to maintain the DBRM library, that is, to delete DBRMs that no longer have a corresponding executable.

Unfortunately the contoken is generated as literals by the SQL processors, and so is at the mercy of compiler optimizers, with changes between compiler versions and between different compilers.

Bernie

------------------------------
Bernie Rataj
IBM Canada Ltd.
Markham ON Canada
https://www.ibm.com/marketplace/ibm-compilers
------------------------------

Original Message:
Sent: Wed May 05, 2021 07:47 AM
From: Jon Butler
Subject: Cobol Precompiler contoken pattern in cobol 6.2

I am unclear if the token is causing a Bind or run-time problem, or you simply are bothered by the difference?

Let me suggest you might switch to use the SQL CoProcessor built into the compiler.  If you use CICS, you can also use the built-in CICS Translator.

In addition to not having to maintain separate products, messages will be listed in-line with the COBOL messages, and you will  get all the new COBOL language features which are not always handled properly by the external processes.

------------------------------
Jon Butler
------------------------------

Hi -

Thanks for the repsonse.
It is not causing any bind issue. But we are seeing the pattern difference. till 4.2  the contoken pattern between load and DBRM is reveresed of first 8 digits. but in 6.2 it looks same.
Did the compiler changed to have them both same?

------------------------------
priyadarasini Esvar
------------------------------

Original Message:
Sent: Wed May 05, 2021 07:47 AM
From: Jon Butler
Subject: Cobol Precompiler contoken pattern in cobol 6.2

I am unclear if the token is causing a Bind or run-time problem, or you simply are bothered by the difference?

Let me suggest you might switch to use the SQL CoProcessor built into the compiler.  If you use CICS, you can also use the built-in CICS Translator.

In addition to not having to maintain separate products, messages will be listed in-line with the COBOL messages, and you will  get all the new COBOL language features which are not always handled properly by the external processes.

------------------------------
Jon Butler
------------------------------

hi Priyadarasini,

We have already answered this question in your other post.

Hope that helps.

------------------------------
Linda Chui
Compilation Technology & Enterprise Products
IBM Canada
------------------------------

Original Message:
Sent: Tue May 11, 2021 01:07 PM
From: Priyadarasini Esvar
Subject: Cobol Precompiler contoken pattern in cobol 6.2

Hi -

Thanks for the repsonse.
It is not causing any bind issue. But we are seeing the pattern difference. till 4.2  the contoken pattern between load and DBRM is reveresed of first 8 digits. but in 6.2 it looks same.
Did the compiler changed to have them both same?

------------------------------
priyadarasini Esvar
------------------------------


Original Message:
Sent: Wed May 05, 2021 07:47 AM
From: Jon Butler
Subject: Cobol Precompiler contoken pattern in cobol 6.2

I am unclear if the token is causing a Bind or run-time problem, or you simply are bothered by the difference?

Let me suggest you might switch to use the SQL CoProcessor built into the compiler.  If you use CICS, you can also use the built-in CICS Translator.

In addition to not having to maintain separate products, messages will be listed in-line with the COBOL messages, and you will  get all the new COBOL language features which are not always handled properly by the external processes.

------------------------------
Jon Butler