On 6 Apr 2010 08:39:36 -0700, in bit.listserv.ibm-main you wrote: >On Tue, 6 Apr 2010 13:28:11 +0200, R.S. <r.skoru...@bremultibank.com.pl> wrote: > >>Of course in every case we should know the meaning of the profiles and I >>believe that the GIM.** profiles will be documented. It does not >>contradict with the APAR statement - the risk details can be still obscured. >>BTW: I bet the case is very bizarre case and it does not affect majority >>of us, BUT the APAR officially falls into category "integrity" and gets >>all the attributes of secrecy. I consider it as SPE (Small Programming >>Enhancement) with disputable qualification. > >Sorry, Radoslaw, but while the implementation may have happened to provide a >functional enhancement that some of you will find useful, we would not have >released an APAR that -requires- those migration actions if it were merely >an enhancement. > >We might have introduced such improved function via an APAR, but it would >have been optional (e.g., "if you want to control function x you can define >this profile", not "if you want to allow the program to continue working at >all you must define a profile"). We do not lightly make such changes >mandatory and force migration actions on our users in the service stream. > >There is a legitimate integrity exposure involved, and the APAR is properly >classified as such. We perhaps should have said a bit more in the >documentation. We're considering whether we can do so, and what we can say >that will convey the magnitude of our concern (though merely the fact that >we did this via an APAR with mandatory migration actions should serve as a >indication that we have serious concerns and there is a legitimate problem >to address).
After watching this thread, I have a couple of comments. The first is that when something like this is introduced, the APAR should give some clue as to how and why people are to use this new function/feature. The discussion shows that far better systems programmers than I are confused about the new function and profile. If people don't implement the change properly so as to achieve the intended goal of the change, it could be worse than useless. At the very least there should be a list of recommended practices. The second is the question of APF authorization. I believe that one of the longer term goals should be to remove the need for APF authorization from all utilities where at all possible. The requirement that IEBCOPY be APF authorized probably should have been removed 20 - 30 years ago since a competitive product seems to be able to do without it. Should IDCAMS need to be APF authorized in order to function. Is IEBCOPY the only reason that SMP/E needs to be APF authorized? If not, can changes be made to eliminate the need? ---------------------------------------------------------------------- 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
