There are obviously (too) many places where what turned out to be incorrect design decisions (or lack of design decisions) have led to the system not working the way it "should". This is popularly referred to as broken-as-designed (BAD).
It is true that typically design defects are not subject to field APARs. But despite some posts to the contrary, that doesn't mean that they must stay defects. Depending on the customer impact, they might be fixed by what used to be called an SPE (which basically is nothing more than an APAR opened internally) or in a followon release. However "dumb" a behavior might be, there is usually a pretty good chance that changing that behavior will break someone. We thus tend to make such changes in "the next release" where feasible (and highlight the change in the migration information) and/or make the customer who is applying service to an existing release specify some option to ask for the behavior change (i.e., not make a change in behavior by default in the service stream). Do we always get this right? No. But we hope we're doing better. Please don't give up on bringing these situations to our attention. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
