Ron, There are all the Navy ships to USS ..United States Ship
Scott Ford Senior Systems Engineer www.identityforge.com On Apr 21, 2012, at 4:39 PM, Ron Hawkins <ronjhawk...@sbcglobal.net> wrote: > Well, shouldn't that be USST? But yes cobber, it could be a contraction of > Unix System Services Table. It could even be Universal Studios Singapore > Table. > > Geez, why is it that VTAM should have a mortgage over these three letters. > I'm going to write to the United States Senate (USS) about this. > > If one has difficulty understanding the context it's their problem, not > mine. You know when someone is talking about a ship, shell scripts or a > modify table which USS they are referring to, so get smart and adapt. > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On >> Behalf Of Dick Bond >> Sent: Thursday, April 12, 2012 2:47 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: [IBM-MAIN] A z/OS Redbook Corrected - just about! >> >> Oh, so USSTAB means Unix Systems Services table. Wonder what that's used >> for, mate? >> >> On Fri, Apr 6, 2012 at 10:20 PM, Ron Hawkins >> <ronjhawk...@sbcglobal.net>wrote: >> >>> 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=/co >>> m.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 >>> >> >> ---------------------------------------------------------------------- >> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
