>Not so; answering the question asked requires only a simple "yes". >And deserves little more.
I, and likely just about everyone associated with the security of the platform, disagree strongly with this statement. It is true that the program itself might or might not directly provide the "keys to the kingdom", but we have found that a program not written to be AC(1) has system integrity problems when bound with AC(1), in a huge percentage of cases. This includes buffer overflows due to improper parameter handling and use of subpools that can be manipulated by unauthorized code running in the same address space. And myriad others. A significant effort was taken, and continues, both within IBM and within the ISV community, to make sure that programs that do not need AC(1) do not have it. If the owner of the module were to tell you that they forgot to include the AC(1) attribute and that AC(1) is appropriate and that as a temporary measure, until they provide a formal fix, you can re-link, that is a different story. But even to re-link, don't you need to know whatever other options were applied? I don't know of a binder directive that is "relink with all previous options but add AC(1)". For example, what AMODE? What RMODE? Should it be RENT? Should it be REFR? Should it be REUS? Peter Relson z/OS Core Technology Design
