Shirley there is a better way to introduce new behavior in a compatible manner, e.g., with a new PARM option. Having two keywords that look like they should be synonyms but aren't is user hostile.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Tuesday, March 3, 2020 9:48 PM To: [email protected] Subject: Re: Two related alias entry address questions On Tue, 3 Mar 2020 17:23:19 -0800, Charles Mills wrote: > ... >Makes my head spin. What was IBM thinking? It is beyond me why one would want >to use one versus the other. I can envision a test case where they behave >differently, but what is the situation where you would actively want to use >one rather than the other? When would you want to use a command that was not >COPY but in your particular situation behaved just like COPY? > Might be history. IBM is loath to change an earlier behavior, no matter how adverse, lest some programmer, somewhere, has come to depend on it. On Tue, 3 Mar 2020 16:35:41 -0800, Charles Mills wrote: >Got it! Not sure exactly what the key ingredient was but I suspect that the >problem was that I had @Gil's un-externally-named entry point: > >BAR DS 0D >... > END BAR > >I changed that to >BAR DS 0D > ENTRY BAR > END > If either IEBCOPY or INCLUDE -ATTR fails to propagate an entry address, even so bizarrely generated, IBM should take an APAR. Of course, for compatibility they'd feel compelled to invent a new option and preserve the old default. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
