On Mon, 7 Dec 2009 09:08:28 -0500, John Eells wrote: > >- A change control record must be opened, and the change justified and >approved. >- The change has to be made, tested, and documented. >- The documentation has to be reviewed and accepted by production control. >- The job has to be changed in the production control system. > Of course, changing the behavior of a pervasive cliche such as "//STEP EXEC PGM=IEFBR14" behind the customers' backs induces similar requirements for review and testing. But if I understand correctly, this is controlled by a PARMLIB option, so customers can elect not to endure the change.
In an analogous situation, many years ago a code generation bug in Assembler was (belatedly, IMO) repaired. I remarked to a developement manager that we were relieved of the burden of maintaining the circumvention we had developed. But he was unexpectedly dismayed: "We must now revalidate all our products in GA, since a code gen change may impact an unknown number of dependencies on the current (incorrect) behavior." >So, naturally without any guarantee that we'll ever do anything...how >would those of you who dislike our solution solve the problem while >meeting the implied requirement for avoiding JCL changes? > Can't. Let the rants continue. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
