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 ---------------------------------------------------------------------- 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
