Rex > Really basic changes, but we use a custom USS table here.
Please see the questionnaire in the post to John Hamman. > Of course, this is assuming that we're all using the TLA "USS" in the correct manner. ... Ron Wells, advertently or inadvertently, when he initiated the thread did all the list subscribers a kindness by using "USSTAB" as the "Subject" for this long-running thread. He could have caused immense confusion by using the "Subject" "System symbols in USS" as he would have been thoroughly entitled (pun) so to do. Chris Mason On Thu, 6 Aug 2009 15:10:22 -0500, Pommier, Rex R. <[email protected]> wrote: >Really basic changes, but we use a custom USS table here. > > >Of course, this is assuming that we're all using the TLA "USS" in the >correct manner. <G, D, and R> > >Rex > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Martin Kline >Sent: Thursday, August 06, 2009 2:21 PM >To: [email protected] >Subject: Re: USSTAB > >I appreciate the continued discussion. It's interesting banter. > >I have indeed opened an ETR with IBM as a low-priority problem. Progress >is >as expected, slow, though I have gotten the support person to agree >there >is/are issue(s). > >I'm not sure how this would be a "requirement." I just want the code to >work >as documented. Untimately, I would prefer the code to work logically and > >precisely under control of the systems programmer. I'm afraid the end >result >will be changed documentation instead. If that's all I get, I plan to >continue >pushing until the documentation clearly outlines the limitations and >restrictions >that are currently hidden in the code. > >As for Chris Mason's reference to "incompetent" developers, I would not >be so >harsh. I certainly appreciate Chris's support and in-depth knowledge of >networks, and have often found his comments to be quite valuable. I have > >never worked for IBM, but I have worked with their support for over 30 >years. >Some time ago IBM would not have tolerated the 'sloppy' implementation >of >system symbols in USS tables. ('Sloppy' is my term). These days, though, >as >with quite a few US-based companies, 'competent' means 'good enough'. >And, 'good enough' means just barely enough to meet the designer's >specs, >ignoring any obvious or discovered shortcomings. It's not the >developer's job >to point out flaws in the design, and oftentimes, doing so only results >in the >developer being reprimanded by "incompetent" managers for going outside >the >scope of the project, even it it could produce a better final product. >It's also >not the tester's job to do more than test the ability of the code to >perform >the bare minimum to meet the design, nor to even understand subtle >characteristics of the environment that could affect the ability of the >product >to work under all conditions. So, not knowing what constraints the >developers >may have had, I hesitate to single them out as incompetent, when it may >actually be the environment under which they work that values quantity >over >quality and causes them to produce less than stellar results. > >Sorry. I read over that paragraph a couple times, and I just don't see >how to >make my point without the soap box. I'll make a note to have my soap box > >burned and the horse buried later. (references to preaching from atop a >soap >box, and to beating a 'dead horse' (overworked subject) to death). > >BTW, for everyone (anyone?) who bothered to read this far, how many use >a >custom USS table? Is it just Chris, Patrick, myself and a couple other >people in >the world? > > >Patrick said: >>The product is "working as designed". If you want this changed you're >going >>to have to submit a Requirement with a very strong business case. >Fixing. >>USS design flaws isn't going to be very high on anybody's list. ---------------------------------------------------------------------- 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
