Hi to you all, wise gal and guys, THANK YOU SINCERELY for all your valuable réactions!
I think the overall conclusion might (!) be: the techies seem rather to be PRO-recompile, while the more development oriented people CONTRA-recompile and hence PRO-copying, and this certainly between ACCEPTANCE and PRODUCTION ! I am a techie, and hence rather PRO-re-compile, while I adore technical beauties, much more than the application solution. But these wise considerations about regression testing and its managing burden when re-compiling lead to my final conclusion: A chacun son métier !. "Every man to his own trade!" (does this sound english enough ? ;-) ) We can't be good at everything Cheers to you all. Jan On Mon, Jun 3, 2013 at 1:27 PM, Jan Vanbrabant <vanbrabant...@gmail.com>wrote: > Hi John, Peter, > > *>> Re. I am also suspicious of Jan Vanbrabant's esclusion of > homologation from this discussion. The word is derived from the ancient > Greek verb homologein, to approve, which becomes homologare, to agree, in > fairly late Latin. (It has a special meaning in Scots law, where it is > used to characterize a process of removing minor defects from contracts, > the remediated versions of which are then given the force of law.)* > > *> Re. As for Jan Vanbrabant's stage names, HOMOLOGATION easily > translates to "(Internal or Product) Quality Assurance" and ACCEPTANCE to > "Client Test". My organization uses both, though not in disparate > technical or physical environments, and always without recompilation.* > This is exactly what it means, Peter ! > > Jan > > > On Fri, May 31, 2013 at 9:40 PM, Farley, Peter x23353 < > peter.far...@broadridge.com> wrote: > >> The problem with recompilation is not purely technical though. ISTM that >> there is far more bureaucracy needed to monitor and guarantee successful >> completion of full regression testing at each recompilation than there is >> payback from using notionally "better" translators and runtimes at a given >> stage. >> >> In the case where each stage from development to production may reside on >> physically and/or technically disparate systems, I admit that recompilation >> seems like a reasonable solution to ensure accurate and effective execution >> at each stage, but again ISTM that the additional verification requirements >> are far too onerous a cost both technically and bureaucratically. >> >> IMHO, of course. We can certainly agree to disagree on this. >> >> As for Jan Vanbrabant's stage names, HOMOLOGATION easily translates to >> "(Internal or Product) Quality Assurance" and ACCEPTANCE to "Client Test". >> My organization uses both, though not in disparate technical or physical >> environments, and always without recompilation. >> >> Peter >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of John Gilmore >> Sent: Friday, May 31, 2013 2:40 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: To recompile or not recompile, that's the question >> >> Predictably I suppose, recompilation gets my vote. The issues >> involved are technical and not management ones, and bureaucratizing >> them never helps. >> >> Development takes some time, and linking the development version of a >> PL/I compiler to that in current production use is always a bad idea. >> It ensures that retrograde technology and performance will be wired >> into newly developed systems. (This may happen anyway, of course; the >> use of the best translator is a necessary but not a sufficient >> condition for high performance. That use can be, often is, >> perfunctory.) >> >> I am also suspicious of Jan Vanbrabant's esclusion of homologation >> from this discussion. The word is derived from the ancient Greek verb >> homologein, to approve, which becomes homologare, to agree, in fairly >> late Latin. (It has a special meaning in Scots law, where it is used >> to characterize a process of removing minor defects from contracts, >> the remediated versions of which are then given the force of law.) >> >> If, as I suspect, homologation here has to do with ensuring that a >> systems meets its functional specifications, it is relevant. >> >> John Gilmore, Ashland, MA 01721 - USA >> -- >> >> 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 >> > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
