Let me emphasize that IEBCOPY is *not* the "program Y" of my recent thread.
The product in question below works fine and absent tearing it open for some other reason, or a customer complaint, I will probably leave it as it is. But you raise an interesting logical point. Formerly my program was compliant with best practices: It did not have to worry about the trustworthiness of IEBCOPY because it was AC=1 and therefore to be trusted. Now, all of a sudden, my program is not compliant (if some posts here are to be believed or followed) because since IEBCOPY is now AC=0, it is now up to me to know whether it may be trusted, and frankly I have no way of knowing. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Monday, March 16, 2015 11:58 AM To: [email protected] Subject: Re: IEBCOPYO (was: APF-authorized ...) On Mon, 16 Mar 2015 13:26:02 -0500, Walt Farrell wrote: >> >>... is now impacted in that calling IEBCOPY causes his program to lose >>authorization/ ABEND/whatever. > >Not true, gil. A program running APF-authorized does not lose authorization by >calling an AC(0) module. It keeps running authorized, assuming, of course, >that the AC(0) module came from an APF-authorized library. .. > I stand very corrected. I thought I used to know that. But let me try again. IEBCOPY has been demoted from "APF Authorized" to "Module residing in an authorized library, marked AC(0), so not designed to be invoked authorized." This somewhat shifts the burden of parameter validation from IEBCOPY itself to any authorized caller. Charles could save himself some doubt by marking one program he mentioned AC(0) (for z/OS 1.13 and higher). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
