Jan, in my experience recompiling is absolutely the wrong way to operate. The most serious drawback is that when developers perform regression testing (and they *do* *always* perform full regression testing, right?) to verify that what worked before their change still works the same, and that the only differences in the file outputs are those expected from the change that they made, the version that they test is NOT the version that goes into production (or into any other stage along the way to production).
Given the system software rollout pattern you have described (and that is the "right", i.e. safe, way to do it, IMHO), the application software running in production *must* always be at the "lowest common denominator" level (i.e., whatever is in production), thus possibly losing any benefit of newer HW/SW levels for the time it takes to finish a system software rollout. The great benefit is that production behavior is predictable and stable. From the developer's perspective, this means NOT using the "latest and greatest" compiler and run-time system features until those features have reached the production environment. Significant differences in compiler facilities do have to be carefully monitored so that any of the broken scenarios you describe do not occur. The standard compile-and-link process must be carefully controlled so that every compile at the development level uses the same standard lowest-common-denominator options and facilities, without the ability for a developer to bypass the standard. The only safe way to support recompilation at each of your several stages along the way to production is to perform full regression testing *at every level* after recompilation is performed. This is a *huge* burden on personnel and systems (people time and CPU/DASD usage among others), especially if you are (as I can suspect from your description) a large shop with many different applications and application groups. Having to perform multiple levels of regression testing significantly slows time-to-market for any application change, which can be deadly to any business model. And to your employment. A dead business pays no salaries (except maybe to the bankruptcy crews... :). HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jan Vanbrabant Sent: Friday, May 31, 2013 10:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: To recompile or not recompile, that's the question Hi wise guys and gals, HOW are you in your shop managing your sources and load modules and the versions of compilers and z/OS? <Snipped> Till now, the application programs are RE-COMPILED in each environment; this in order to avoid the slightest problem. For example: </Snipped> Please, your thoughts! Jan -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
