Peter > I'd really love to understand why on earth people like you are defending that term in the name of VTAM.
If it were only VTAM, the anti-SNA bigot of which "I'd really love to understand why on earth" there are so many "people like you" might have a point. But since "that term" applies now not just to the SNA component of Communications Server but also to the highly trendy IP component of Communications Server in the shape of the "TN3270E" server, your case falls down about your ears and lies shattered on the ground. In case you are ignorant of this point as seems very likely, the benefits of the Unformatted System Services (USS) command LOGON (and a pale shadow of LOGOFF[1]) and messages including IP-specific variables are available to TN3270E clients - all very "now"! As I pointed out before I did a literature search on "USS" and it was evident that, by and large, the generally official *documentation* which I was searching in the IBM bookshelf stuck to the rules. It was only in a programming context such as the "Health Checker" that the misuse of USS was common. I don't know where the "Health Checker" came from but I have a suspicion that it was created by some bright IBMer in relatively idle time without any reference to any official guidelines - a naissance applying to very many highly successful products over the years.[2] Once presented to the powers-that- were, everyone jumped up and down in great enthusiasm and immediately had it massaged it into an offering for customers. Did somebody point out that all the uses of "USS_" were illegal? It's just possible. For example, I guess if John Eells had had anything to do with it - and he might have, he might have said something and probably would have. What's just about certain is that the "suit" responsible would have asked whether or not there would be any benefit for the cost involved in clearing out the "unapproved" abbreviation - and he may have known enough not to need to wait for an answer. It's at times like this I recall CICS and its BALR 14,14! > A guess that this component had to pass naming convention, quality assurance and whatever other boards within IBM. I guess your guess is very probably 180 degrees wrong! > The keys are still named USS_xyz. This somehow proves to me that the abbreviation is largely accepted with IBM itself. An argument on foundations of quicksand. Does the relative absence of "USS" in the z/OS UNIX bookshelf mean nothing to you? For a start, there are 11 books and only 5 actually happen to show up when "USS" is keyed in the bookshelf "Search text" box. Try using some logic! Well, I just checked all the hits in all the manuals, a task taking less than a minute - that should be a salutary observation! - and the "Health Checker" is the chief culprit causing all the hits in the "Planning" manual. If my guess regarding the "Health Checker" is about right, you have lost your only paddle and are drifting helplessly. Since you were relying so terribly much on the evidence of the "Health Checker" function to support your shaky argument, I dug out a possibly helpful reference on what the "Health Checker" was all about: Exploiting the IBM Health Checker for z/OS Infrastructure, December 2010, REDP-4590-01 http://www.redbooks.ibm.com/abstracts/redp4590.html There's a gloss in the "Background" section which has the objective to indicate that this was a logical development but one can read between the lines and guess that, possibly following a disaster with a customer with clout after which somebody said why the <several expletives deleted> didn't IBM tell us that was a stupid value to set for that parameter that ruined our business for an hour/day/week/whatever, a quickly convened panel of experts came up with plan to supply what became to be known as the "Health Checker".[3] I can well believe that proverbial skids were placed under the team responsible and they were supplied with all the necessary "get out of gaol free cards" to bypass any checks on adherence to naming standards or whatever. Reading the "Background" section, one is struck by how wonderfully the legend is presented. I wonder how a contemporary account as opposed to an account benefitting from hindsight would read. I was going to say I wondered why it took three years for the function to appear from conception to first delivery but, reading more closely, "early 2000s" is not at all necessarily 2000 and could just as easily be 2003. It's good to have a "word-smith" available when you want to present a blameless account! > You won't change this anymore, like nobody else will. "USS" has become the defacto standard name for z/OS UNIX System Services. I suggest - without any great expectation that the suggestion will be followed in your case - that, if you must misuse the term "USS", you do so in a context which removes any possibility for ambiguity. This is a goal which could so much more easily be achieved by the use of the term z/OS UNIX or zUNIX.[4] Meantime if I spot a potential ambiguity down to misuse of "USS" - likely only if the thread involves Communications Server or another SNA or IP product and TELNET - I reserve the right to protest, a popular activity these days - assuming I'm not beaten to the punch! > ... defacto ... Which, of course, brings to mind, its logical companion, "de jure", and your arguments fail the necessary legal tests. However the only penalty hanging over you, is the possibility - probability? - to be misunderstood - in perpetuity ... Chris Mason [1] Unfortunately the author of what is now RFC 2355 did not appreciate the possibilities for switching from LU-LU session to SSCP-LU session while a session is in progress and so did not allow for a simulation of the presentation of USS messages while a session is (supposedly) in progress. Thus an important use of USS messages for the purposes of supplying variable information useful for the resolution of problems experienced during an active session is lost. [2] I used to use the VTAM DISPLAY NCPSTOR command wrapped up in REXX Clists under NetView for the purposes of presenting information from NCP control blocks. If I had persisted with this endeavour I might have done just about precisely what IBMer Ernie Gilman was doing at much the same time in working up the product which eventually became NTuneMON. This is an example of an individual following up an idea and developing a prized product as very much a solo effort. [3] I know of what I speak here having gone through a similar exercise following a disaster with a building society in the UK in 1972 when, unbeknown to IBM technical folk, they decided to implement and instantly go live with paging for the first time - because they happened to have a 370/145 - with their essentially BTAM-based country-wide pass-book processing system. This then justified the cartoon of a skeleton with his - or her - bony hand on the terminal which was circulating around that time. The solution on that occasion - which I well remember being told about over a pint and almost spilling my beer as the reason rapidly dawned - was to institute a quick education program for all technical specialists with customers at risk together with a program to pass the education on to the customers - tout de suite! [4] Some people have been known to mention that APARs using "USS" for "z/OS UNIX System Services" somehow justifies - probably the words they have in mind is "de facto" - what I describe as a misuse. Well, I, with the expression "Hoist with one's own petard" to the fore have found an APAR which has explored the possibility to use the term zUNIX - and good luck to it! http://www-01.ibm.com/support/docview.wss?uid=swg1OA33808 - 2010-07- 27 (my birthday!) Also the "IBM ISPF Productivity Tool for z/OS, Users Guide, Version 6 Release 1 Modification 0" manual http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/topic/com.ibm.ipt.doc_6. 1/iqiugb00.pdf appears to have found the term "zUNIX" useful. On Sun, 13 Feb 2011 07:48:13 -0600, Peter Hunkeler <[email protected]> wrote: >>Perhaps some form of hybrid acronym like zUSS >>could serve as being both highly compact and descriptive, while >>avoiding potential confusion with prior art. > >Jim, >As much as I do respect you, I can't agree with that suggestion. > >z/OS' Health Checker compontent has chosen to name its z/OS UNIX related >keywords beginning with the letters USS. A guess that this component had to >pass naming convention, quality assurance and whatever other boards within >IBM. The keys are still named USS_xyz. This somehow proves to me that the >abbreviation is largely accepted with IBM itself. > >I'd really love to understand why on earth people like you are defending >that term in the name of VTAM. You won't change this anymore, like nobody >else will. "USS" has become the defacto standard name for z/OS UNIX System >Services. > >-- >Peter Hunkeler ---------------------------------------------------------------------- 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
