> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Patrick O'Keefe
>
> On Tue, 2 Oct 2007 12:35:59 -0400, Peter Relson 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?
For a "work in progress", see SHARE Requirement SSMVSS07009 and its
discussion regarding DFSMSdss's handling of the "dataset changed
indicator" bit in the VTOC on full-volume RESTOREs (it unconditionally
turns them "off"). There is also some discussion of this in the
IBM-MAIN archives starting around December, 2006. So far, IBM has
offered "temporary relief" via APAR OA20907.
What's omitted from the Requirement and other related discussions is the
fact that DFSMSdss handles the "changed bit" differently on a "logical"
(DATASET) RESTORE: If the "changed bit" was originally "on" at DUMP
time, it's turned "on" in the VTOC after RESTORE DATASET. In my
original PMR that eventually led to the Requirement (and indirectly to
APAR OA20907), DSS Level 2 "admitted" that this was due to an "incorrect
implementation" of a nearly-decade-old APAR for a different situation,
and that "fixing" that now would incur too much risk of "breaking" other
things that now rely on that counter-intuitive behavior. I guess that
would be "B-A-F" (Broken As Fixed)?
-jc-
----------------------------------------------------------------------
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
