Hi,

We decided to use the COBOL dwarf with source compiler options for use in our debug tools.
This greatly facilitates the deployment of programs, without needing to synchronize the deployment of compilation listings at the same time as the programs (solution used until now by our debugging tools). This also speeds up the debug setup process since the necessary informations are stored directly in the program and it is no longer necessary to access the listing to extract the information needed by the debug tools.

We would like to completely abandon the preservation and storage of compilation listings which, once past the stage of looking for errors during compilation, are no longer of much interest.
However, it may sometimes be necessary to consult a compilation listing outside of the use of debugging tools.
The informations produced by the dwarfdump, CDADUMP utilities are not humanly usable.

Ideally, one should be able to reconstruct a pseudo compilation listing from the dwarf with source information, which would look like the compilation listing produced by the COBOL compiler.
Having consulted various documentation on the subject, it seems possible to me, but the work to be done is very important.

Do you know of a solution that would already do this task of rebuilding an equivalent compilation listing  from the dwarf with source information?
Has the IBM Enterprise COBOL compiler team ever considered producing a utility that accomplishes this task? (I'll open a request on the Ideas site about this).

Thanks.

Hi Dennis,

I strongly recommend clients keep their compiler listings, ideally compiled with LIST, even if they're not being used, as they may serve other purposes down the road.

Constructing a listing-like thing from DWARF data is not on our radar, though I believe DWARF is an open format and you could always build your own DWARF-to-listing tool if you wished. (Though in my opinion, it's not worth the effort compared to producing and storing the listings).

Compile listings that match the load module have always been an audit requirement at our shop.  I don't see that changing any time soon. The auditors used to insist on printed versions of the listings; it took years to get away from that.  

You did not say which debugger your are using, but DWARF works fine with IBM DEBUG, but if you use Xpediter, it will cause problems.

What is the motivation for not keeping the source listings for production-level code?

It's not clear to me what you are gaining by trading "not using as much disk storage" for "needing to run a utility one or more times" to recall compiled listing.  It would seem to me that a reasonably orderly deployment step in your process would take care of this automatically.

Hi Scott,

The main reason is not to manage the same information several times in different formats.
The dwarf information with source contains a priori the same information as the compilation listing.
The main use of build listings today is for debugging activities. With dwarf the listing is no longer necessary.
Consultation of a compilation listing outside of debug activity is very occasional and we can allow to have a process of reconstructing a pseudo listing from dwarf information.
Conversely, if we keep the compilation listings then there is no longer any objective reason to use the dwarf information, (our debugging tools work directly with the compilation listing, without any special preparation).

I have no dog in this hunt, but I think practicality far outweighs theoretical purity for this Socratic exercise.

-----

The main reason is not to manage the same information several times in different formats.  Counterpoint:  storage is cheap.  It's even cheaper if you archive the files off-system.
The dwarf information with source contains a priori the same information as the compilation listing.  Response:  So what?  As indicated above, there is no utility to produce a listing from a DWARF file.
The main use of build listings today is for debugging activities.  Ok. but they can also be used to verify "meta" information like when the compile occurred, what compiler options were selected, etc.  With dwarf the listing is no longer necessary.  An interesting conclusion, given the previous facts.  Just because something is theoretically possible doesn't make it practical.
Consultation of a compilation listing outside of debug activity is very occasional and we can allow to have a process of reconstructing a pseudo listing from dwarf information.  Agreed.    
Conversely, if we keep the compilation listings then there is no longer any objective reason to use the dwarf information, (our debugging tools work directly with the compilation listing, without any special preparation).  Conclusion:  Keep the compiled listings, don't generate DWARF files.  You've made the point that you have no need for the DWARF file today.  Revisit this conversation when your debugger uses a DWARF file.