Discussion posted 3/28/08 by Serenity Thompson
Details:
karlacope
I am interested in finding out if anyone has customized ChangeMan ZMF to take advantage of the COBOL compiler options 'CICS' and 'SQL.' This is the recommended method rather than running separate pre-compile steps. It seems like a good idea but I’m not sure the customization effort would be worth it. Has anyone done this?
Posted 3/19/2008 7:50 AM
lbjerges
About threee years ago we implemented the DB2 coprocessor in Changeman COBOL compiles in a test environment.
Our main goal at the time was to reduce the number of steps and file I/O in the Cobol stage and also draw benefits for the developers doing interactive debug (nicer listings).
At that point in time however the feature was not very mature and required a lt of PTFs in the IBM products.
We finally got it to work however and found out that the elapsed time and excps actually was higher than doing a stand-alone pre-compile. The listing was OK however.
The reason that we abandoned the project at the time was the fact that the co-processor had a number of ideas on what the embedded Sql should look like, e.g. commands over multiple lines, caps on/caps off and so on. This would obviously mean that we could not make the transition unknown to the developers since there (possibly) was an impact on their code.
Since then we have implemented IBM ́s bind manager executing on top of the pre-compiler which complicates (it ́s still possible) the implementation of DB2 co-processor and this is the reason that we haven ́t really looked at it again.
In retrospect I would say that, for us, the skeleton customization was 20% and work fixing IBM features (at the time) was 80% of total time spent
Regards Lars
Posted 3/20/2008 1:37 AM
#ChangeManZMF
#post3c4483f1f1
#oldforumpost
Page 1 / 1
Discussion posted 3/28/08 by Serenity Thompson
Details:
karlacope
I am interested in finding out if anyone has customized ChangeMan ZMF to take advantage of the COBOL compiler options 'CICS' and 'SQL.' This is the recommended method rather than running separate pre-compile steps. It seems like a good idea but I’m not sure the customization effort would be worth it. Has anyone done this?
Posted 3/19/2008 7:50 AM
lbjerges
About threee years ago we implemented the DB2 coprocessor in Changeman COBOL compiles in a test environment.
Our main goal at the time was to reduce the number of steps and file I/O in the Cobol stage and also draw benefits for the developers doing interactive debug (nicer listings).
At that point in time however the feature was not very mature and required a lt of PTFs in the IBM products.
We finally got it to work however and found out that the elapsed time and excps actually was higher than doing a stand-alone pre-compile. The listing was OK however.
The reason that we abandoned the project at the time was the fact that the co-processor had a number of ideas on what the embedded Sql should look like, e.g. commands over multiple lines, caps on/caps off and so on. This would obviously mean that we could not make the transition unknown to the developers since there (possibly) was an impact on their code.
Since then we have implemented IBM ́s bind manager executing on top of the pre-compiler which complicates (it ́s still possible) the implementation of DB2 co-processor and this is the reason that we haven ́t really looked at it again.
In retrospect I would say that, for us, the skeleton customization was 20% and work fixing IBM features (at the time) was 80% of total time spent
Regards Lars
Posted 3/20/2008 1:37 AM
#ChangeManZMF
#post3c4483f1f1
#oldforumpost
This is an old migrated post that has been assigned status Complete.
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.