Tim, I have to disagree in part with the statement you made below that "... it couldn't be avoided". It most certainly *could* have been avoided.
It may have been a "... reasonable, responsible technical choice" from IBM's more-than-occasionally myopic point of view, but not necessarily the best choice, either technically or politically. A better choice, IMHO, would have been to use the XL C/C++ back end which supports not only load-module output but also supports architectures back to before the G1 series (the XL C/C++ documentation for ARCH(0) says: "Produces code that is executable on all models."). All the benefits of newer-architecture instructions and advanced optimization algorithms would have been made available without *requiring* program-object output and thus PDSE storage. As well, the choice to implement debugging information in DWARF2 format in no-load program-object segments should NOT have meant that output object code was *necessarily* program-object-only output. When compiler option NOTEST is in effect there should be no reason whatsoever to force the compiler to produce a program object. And again, the XL C/C++ back end would have been ideal in this case, able to produce either load-module-compatible or program-object-required output, UNDER THE CONTROL OF THE END USER PROGRAMMER and their management, and depending technically on whether any program-object-only COBOL features were used in the source code. For instance, writing OO COBOL source code that uses classes and methods, etc., would have been a very reasonable cause to force program-object output. A COBOL source program that uses no OO features and is compiled with NOTEST should be able to generate a load-module-compatible output executable. And debugging software available from several ISV's would have supported debugging without using the IBM DWARF2 information at all, as they do now, and let the best debugger in the market win the hearts and minds of the users and their management. Competition is good. Obviously we are not going to get that choice, but it is one that IBM *could* have given us. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Timothy Sipples Sent: Thursday, September 19, 2013 11:37 PM To: [email protected] Subject: Re: PDS/E, Shared Dasd, and COBOL V5 <Snip> I am not thrilled that there's a PDSE prerequisite for Enterprise COBOL 5.1. I don't like any prerequisites whatsoever if they can be avoided. In this case, it couldn't be avoided. This path was the reasonable, responsible technical choice in order to deliver to you, our great customers (and to new customers) wonderful COBOL innovations, both immediately and continuing over the long term. Compilers are both hard to do and critically important, especially as microprocessor-related physics keep getting more challenging. This new backend puts COBOL firmly back on the development path it deserves as one of (if not the) preeminent enterprise programming languages. I couldn't be more thrilled about that. </Snip> -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
