Back in early February, I sent off this "comment" to the "redbooks" site:
<comment> To whom it may concern, - This feedback concerns redbook z/OS Version 1 Release 13 Implementation, SG24-7946-00, which is described still to be in "Draft" status. - Recently I wanted to check on what z/OSMF was all about. Expecting to be more quickly enlightened by finding a suitable redbook, I tried "z/OSMF" as a search word on the "redbooks" site. There were 3 "hits", the first, gratifyingly, was entitled "z/OS Management Facility". The other two were "z/OS Version 1 Release xx Implementation", where xx was 12 and 13. I happened to notice the following at the beginning of the "z/OS UNIX System Services" chapter in the release 13 redbook: <quote> z/OS UNIX System Services, is an element of z/OS, is a UNIX operating environment, and is implemented within the z/OS operating system. It is also known as z/OS UNIX. In addition, there is a short abbreviation called USS. </quote> How very curious, I thought. How did this mistake creep in? I then checked the beginning of the "z/OS UNIX System Services" chapter in the release 12 redbook and found that the curious addition had been slipped in only in the later V1R13 edition: <quote> The UNIX System Services element of z/OS is a UNIX operating environment, implemented within the z/OS operating system. It is also known as z/OS UNIX. </quote> Since the V1R13 redbook is still in draft status, the inappropriate text can be removed. - First, in order to confirm that the abbreviation sanctioned by the authors of the manuals when UNIX System Services was introduced, we can pick any of the "front-line" manuals, the OS/390 MVS Initialization and Tuning Reference being one: <quote> CHANGES Summary of Changes ... As part of the name change of OS/390 OpenEdition to OS/390 UNIX System Services, occurrences of OS/390 OpenEdition have been changed to OS/390 UNIX System Services or its abbreviated name, OS/390 UNIX. ... </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA1E211/CHANGES Thus we have it confirmed that "OS/390 UNIX" is the supported abbreviation, clearly to be transformed to "z/OS UNIX" when z/OS was introduced and that there is nary a mention of any other abbreviation. After all, one abbreviation should be sufficient, shouldn't it? In case there is any doubt over the ancestry of this other abbreviation, we have the following web page in order to remind us what, within IBM, is the correct attribution: http://www-01.ibm.com/software/globalization/terminology/u.html#x2042481 <quote> IBM Terminology ... This site contains terms and definitions from many IBM software and hardware products as well as general computing terms. ... unformatted system service (USS) A communications function that translates a character-coded command, such as a LOGON or LOGOFF command, into a field-formatted command for processing by formatted system services. See also formatted system service. ... USS See unformatted system service. ... </quote> Now there are some - particularly to be found in the IBM-MAIN list - who will swear that this is now out-of-date and so the abbreviation is vacant. Well, it's evident they haven't been paying attention to a function which may well have been assisting them to access TSO through an SNA-oriented TELNET server as recently as today! Nor perhaps a function which may be assisting them to logon to TSO (or other applications supporting 3270s) using an OSA feature configured as an ICC. But then there are none so blind as those who will not see! While locating the above reference, I found the following: Glossary of z/OS terms and abbreviations http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zglossary.doc/zglossary.html Note that this does *not* include the second abbreviation you propose but does, of course, include the first: <quote> z/OS UNIX System Services (z/OS UNIX). z/OS services that support a UNIX-like environment. ... </quote> Another point I noticed was the inherent confusion likely to be caused by anyone searching the IBM site for this abbreviation. The 10th "hit" can be guaranteed to confuse anyone familiar only with the persistent misuse of this abbreviation: "USS messages sent to terminal users" http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.istmnc0/f1a1c69005.htm Yes, you are right, it's about time this misuse was addressed thoroughly by IBMers. If there are still any lingering hesitation, there is always this seminal post from John Eells which makes the position clear: <quote> Re: USS misuse Tue, 28 Jul 2009 09:55:04 -0700 Eric Bielefeld wrote: I still think that IBM should have chosen another acronym for Unix than USS. I believe VTAM USS table is still valid, and still used, so it is confusing to me that IBM should use the same acronym for something that is still in use. <snip> We did not chose "USS" as an acronym for z/OS UNIX System Services. It's not on the list of names people are supposed to use, and nobody in IBM should use this abbreviation to mean z/OS UNIX System Services. (Anyone from IBM who thinks differently should contact me so I can tell them why they're wrong.) In reality, herding cats is easier than making absolutely sure that everyone uses the correct full and short names all the time in all contexts, formal and informal, but we keep trying. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [email protected] </quote> But I expect you noticed the final lament reflecting Hamlet's observation: <quote> But to my mind, though I am native here And to the manner born, it is a custom More honor'd in the breach than the observance, </quote> There is also a question to be answered as to why, in the whole z/OS UNIX System Services bookshelf where surely such a seemingly convenient abbreviation would be in use ad infinitum, only 5 manuals out of 11 actually contain the abbreviation. There are a total of only 18 affected logical pages, of which 11 in the Planning manual can be ascribed to one notable "stray cat", the infamous "IBM Health Checker for z/OS" program.[1] Of the remainder, a paltry 5 mistakes in text - 1 introduced with V1R13[2] - can be corrected by being replaced with "z/OS UNIX" and a still more paltry 2 mistakes in "code" could also be similarly corrected. One is a comment - and there is space available - while another is a log file heading which is highly unlikely to be sensitive to programming.[3] I should probably spend some time submitting RCFs to get these misuses corrected. It's even debateable whether any harm would be done by having the Health Checker program fixed. This is all a matter of formal correctness which some reject as too rigid an approach to this some would say theoretical misuse. I'm thinking of the denizens of the IBM-MAIN list again, of course. However, it is not quite so straightforward. There is one environment where even on one logical page within the manual, the abbreviation can be found in its correct and in its incorrect guise, the description of the EZZ6035I message - which covers the diagnostic codes explaining problems with the SNA-oriented TELNET server, TN3270E - in the z/OS Communications Server IP Messages: Volume 4 (EZZ, SNM) manual. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d1b0/6.23 Yes, the instances of the incorrect use are well separated from the instances of the correct use but that is of no consequence when a computer is doing the searching. Also explaining the incorrect use is not really that helpful since the correct use - as is its right - is not explained. So this exposes the bright sparks who say there is no ambiguity when wallowing in misuse. Well, I've news for them all, there is ambiguity! But this only leads to another reason why this misuse is insidious. A relatively novice system programmer, led astray - by all the "stray cats" - is very likely to acquire an orientation towards the abbreviation which will need to be wiped clean - or set aside - unnecessary mental gymnastics - should he or she be tasked with supporting the Communications Server IP SNA-oriented TELNET server - or possibly some sort of "outboard" SNA-oriented TELNET server - or with supporting an OSA feature configured as an ICC which is also employed in order to access SNA applications. I could be severely judgemental and propose that there are those who make their views known in the IBM-MAIN list who seem to want to confuse these upstarts who are entering the z/OS fold - but I won't be so harsh! As evidence of this point, I can bring up two instances, curiously from the same person who, even after I had explained his first misconception, was so focused on the pernicious misuse that he made essentially the same mistake a few months later. If that doesn't indicate how destructive this misuse is, I at a loss to know what further proof is needed! First instance - February 2009:[4] <quote> I have the following entry in my USSTAB: P39TMMVS USSCMD CMD=P39TMMVS,REP=LOGON,FORMAT=BAL USSPARM PARM=APPLID,DEFAULT=TMONMVS When I key in P39TMMVS we are really getting TMONMVS as the executable. What I don't understand is what path is followed to execute TMONMVS? </quote> Second instance - July 2009: The post which lead to the evidence in a thread which discussed lack of security: <quote> I had one once, circa 1992-1993. ... Someone got the uss screen, was able to get into the production CICS, ... </quote> The evidence: <quote> Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece. </quote> I have also recently been dealing with some IBM-MAIN contributors with Southern or South-eastern Asiatic names - as far as I can tell - who blithely use the abbreviation in its incorrect form even while the topic under discussion is the SNA-oriented TELNET server. As the introduction to the famous TV series had it: "Confused? You soon will be!". I rest my case. - [1] If justice were served, the responsible programmer would have very sore knuckles! [2] Actually there is here another abbreviation which is wrong only in that, in the whole z/OS UNIX bookshelf, it is not explained. It is explained in the MVS Data Areas Volume 1 manual as CSR = Callable Service Request. Prepare to be an intrepid explorer if you need to make sense of z/OS manuals! [3] The manual at fault here is a "sister" manual - by title - to the original manual - strangely enough both relating to a component which appeared *before* the general change from OpenEdition to UNIX System Services - which "strayed". This was "OS/390 UNIX System Services Parallel Environment: MPI Programming and Subroutine Reference, SC33-6696-00. It is noteworthy is that, when SC33-6696-01 appeared, the aberration had been expunged. SC33-6696-00: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IPEPRE01/ SC33-6696-01: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASSPRE00/ Also the two "sister" manuals eschewed the misuse - until the log file header appeared. [4] There is sufficient text here in order to enable the actual posts to be unearthed for anyone who needs proof of everything. I wouldn't want to embarrass the poor chap by making it too easy to find those posts! </comment> I have recently received the ITSO e-mail - thanks to information from John Gilmore that such a service was offered - indicating that the final version of "z/OS Version 1 Release 13 Implementation" was now available. Not only was the offending text describing the supposed additional abbreviation removed but - almost completely - all other appearances in text were removed where there wasn't a reference to an incorrect use in report output. Having struggled with shuffling text within the bounds of presentation pages over many years, it's understandable - if a little disappointing - that the corrections didn't extend to the many diagrams. I'm aware that (a) correcting the diagrams could have been rather laborious with 3 characters expanding to 9 - on one line but two times 4 characters on two lines - (b) the person in charge of the text source may not have charge of the source for the diagrams. The "almost completely" refers to 11.8, "Hardware Instrumentation Services miscellaneous update" where there may have been some doubt over some external use of the abbreviation and so the change was not introduced. Thus 2 changes were missed. Interestingly enough, these missed changes appear before the "z/OS UNIX System Services" chapter. All dozen or so text appearances from within this chapter and in later chapters were corrected. >From the acknowledgement I received from the "redbooks" site I believe I have >to thank my erstwhile - John Gilmore would surely use the word "quondam" here! >- colleague - and I hope he will not object to my adding the complementary >complimentary adjective - dapper Paul Rogers! - Chris Mason ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
