Martin > 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).Is that "issue" as in "issue" or "issue" as in "problem". Only when they acknowledge the latter are we going to see some progress.
Perhaps you can present the support folk with the questionnaire I put in the post to John Hamman as a way of showing that upgrading to V1R8 is a risk for certain customers - the ones about whom you were forlornly (BTW ...) asking - and could be a continuing risk for such customers every time the systems programmer dreams up an installation-defined system symbol. That may affect the priority within IBM - if there's any of the old IBM spirit left! > I'm not sure how this would be a "requirement." I just want the code to work as documented. Ultimately, 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. I'm not sure I agree with Pat's statement that this is "working as designed" and so to be fixed, needs a "requirement". Perhaps we need to analyse what might/should have been in the mind of the "designer". Clearly the requirement addressed here is to allow system symbols to be used in USS messages as they are used in other definition members/files such as the list I originally found in the Communications Server SNA (VTAM) Network Implementation Guide - although we must regard USS messages as special in comparison with other definitions since they imply "run-time" substitution. It will never have been in the mind of the "designer" that existing text, whether with an explicit or an implicit "&" character, could cause substitution. He/she may also not have appreciated that this risk was enhanced - and extends indefinitely into the future - because an installation can define its own system symbols. That this risk exists moves the appeal for a "fix" away from a "requirement" and back to conversion of a "working as coded" to "working as designed". But how? The cat is now out of the bag. Because of the continuing risk aspect, I'm afraid the only realistic way - and the ideal way because the end result is as it should have been in the first place - is to cause all users who have exploited this new function - one hopes only a few although it has been available now for three releases - to discover that it no longer works. They will be obliged to reassemble and linkage edit their USS tables with a new (sub)operand in the affected USSMSG macros. They will discover this when they go the release which incorporates the APAR created for those customers, if any, who got bitten by the typically hidden "&" character (assuming 3270 data stream orders are not skipped). They will be incandescent with rage of course - and the words "incompetent" or "sloppy" may well be in free use - but at least - assuming the responsible systems programmer has not been "let go" in the meantime - they will be able fairly easily to introduce that change. Taking the most likely explanation as to how this hole came to be dug, the "incandescence" will have been a direct consequence of the so-called "economy" with development resources and "true accounting" will have imposed itself as it always does. If there are still management guru-inspired procedures in place whereby a customer "rates" IBM, the scores should reflect what should have been an unnecessary interruption to corporate life.[1] Meanwhile if any customer is actually unfortunate enough to be "stung" by the lurking "insect", the call to IBM support will quickly - one hopes - uncover the APAR which fixes the problem - or - the systems programmer using IBM's equivalent of Google may discover it for him/herself. This will be necessary only from the time that Communications Server IP development finally get the system symbol support right - perhaps with help, and certainly acquiescence, from the VTAM side of the house - packaged into the PTFs which go with the APAR up until the z/OS release which incorporates the APAR. All the time one hopes that some attention is also paid to the documentation. > ... doing so only results in the developer being reprimanded by "incompetent" managers ... All this talk of pointing out infelicities in what one is handed down from above reminds me of one afternoon when I was a trainee and a second-line manager asked for a flip chart to be drawn up for a presentation he was about to give. I pointed out that, given the nature of the data, it shouldn't be a line graph but a bar chart. The look said just do what your told! > 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? The important point here is that there are three options for presenting access to the z/OS VTAM applications to a TN3270 client using the z/OS TN3270 server. I expect that minimally every z/OS user needs one of these options to get from the system programmers' PCs to TSO[2] - unless all the systems programmers access TSO via an OSA-ICC feature's TN3270 server or similar. The three options are as follows: 1. If DEFAULTAPPL and USSTCP are not in effect for the TN3270 client's "clientid", the TN3270 solicitor panel[3]: Enter Your Userid: Password: New Password: Application: This is, of course, massively boring and unfriendly. 2. If DEFAULTAPPL is in effect for the TN3270 client's "clientid", the named typically network solicitor application of which the IBM offering is NetView Access Services will be used. 3. If USSTCP is in effect for the TN3270 client's "clientid", the named USS module will offer something like the logging on (and emergency logging off) environment the systems programmer was used to when using access through a "terminal" directly under the control of VTAM - or, these days, something like the OSA-ICC feature TN3270 server. I would expect no customer systems programmer so mistreats his/her users as to use option 1 and so the choice appears to be between options 2 and 3. Given that programs cannot be relied upon always to be running, does it not behove the systems programmer to advise how TSO can be accessed in the case where the network solicitor application is not running? In that case a well-ordered installation should offer 3 as a backup option where the default application advised in USS message 10 is to log onto the network solicitor application - and not actually use option 2 at all. May I even suggest that the - friendly version of the - name of the network solicitor application is "preloaded" into the equivalent of the "LOGON APPLID" field in USS message 10 - with the MDT bit set in the preceding SF field attribute of course.[4] Thus ideally, *all* z/OS customers should be using USS tables - thereby, unfortunately in a sense, increasing the chances that this enhancement will cause grief somewhere. In any case, given all this talk of reluctance to touch the "house of cards", there must have been a critical mass of customers demanding this enhancement for it to have seen the light of day in however crude a form! Chris Mason [1] I think messed-up USS 10 messages may be what Ken Klein imagined had happened in his post of "Tue, 28 Jul 2009 08:09:01 -0400" in thread "USS misuse (was Re: Mainframe hacking)". [2] The customer where I work from time to time made a big noise about having thrown off CICS as an SNA application last year. [3] In the current context the placing of the cursor on the panel as presented is instructive. If OLDSOLICITOR is specified, the cursor is placed after the "Enter Your Userid" field. If NOOLDSOLICITOR is specified, the cursor is placed after the "Application" field. NOOLDSOLICITOR is default which means in some release of z/OS or its predecessors, the cursor behavior changed without a parameter needing to be specified - in violation of what used to be an IBM iron rule! [4] This is what the customer where I work from time to time does but without the "preload/MDT" trick. Currently, users - and they are not all system programmers - have to enter "S" in order to access SuperSession. Having just had this "preload/MDT" idea, I'm going to suggest it for when I am next on site! One less keystroke - I mean you have to examine the keyboard to find the "S" key - and the key to be hit being most easily accessed by right- handed people - has to be a productivity gain! On Thu, 6 Aug 2009 14:20:53 -0500, Martin Kline <[email protected]> wrote: >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
