Chris, I took your advice and read this post, but then I took it to a higher authority for validation. Yes, I googled "acronym USS.'
Mate, I'm sure I don't have to tell you that the internet holds the keys that unlock all mysteries, and for this one I was horrified to find that for all your hard work, the first hit in Google just simply did not support your position. There was the site with all the answers staring me in the face, waiting for the USS conundrum to be unraveled at a hit labeled "USS - Definition by AcronymFinder." I mean, this has to be place to find the correct meaning of an acronym - forget all these red books and stuff. And so I curtailed my googling activities, sallied forth, clicked my mouse button, and infiltrated this place of purveyance to negotiate the reading of some contracted comestibles. And there it was, on the fifth line of the list: "Unix System Services (IBM)." I'm afraid there was no mention of that other meaning you are always talking about. I mean, based on this unassailable reference it is hard to believe that Unformatted System Services was ever abbreviated to USS, and probably should not have been because all the math's majors working in mainframes back then would have immediately been misled into thinking one was talking about the Uncorrected Sum of Squares (did you know that SAS has a USS function - you should write to them and get them to change it). So I'm afraid we have Internet 1, Chris nil, and we should all start using USS the way God and Google intended us to. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Chris Mason > Sent: Wednesday, March 21, 2012 5:35 AM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] A z/OS Redbook Corrected - just about! > > 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.i > bm.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 > ee...@us.ibm.com > > </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 > lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
