On Tue, 2 Oct 2007 12:35:59 -0400, Peter Relson <[EMAIL PROTECTED]> wrote:
>... >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). >... Occassionally there are BAD situations where the "dumb" behavior amount to system integrity exposures so IBM decides to move ahead with fixes anyway. A case in point: a significant interaction between Websphere and TCP/IP that can exhaust TCP/IP's (and VTAM's) alloted allocation of ECSA, and potentially, all of MVS's ECSA. While IBM didn't oper any APARs (as far as I know) there has already been one fix to Websphere and, according to the grapevine, a TCP/IP fix and another fix to Websphere in the works. On the other hand, there was a VTAM perfomance issue that (I think) resulted in a PMR being closed as WAD. So the user submitted a SHARE Requirement. The Req was rejected because implementing the requested function would have left VTAM in violation of APPN specs. So the user is left with a significant perfomance problem. If both PMRs and Requirements result in no solution, what is next? How do we bring such things to IBM's attention? Pat O'Keefe ---------------------------------------------------------------------- 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
