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:[email protected]] On > Behalf Of Dick Bond > Sent: Thursday, April 12, 2012 2:47 PM > To: [email protected] > 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 > <[email protected]>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:[email protected]] > On > > > Behalf Of Chris Mason > > > Sent: Wednesday, March 21, 2012 5:35 AM > > > To: [email protected] > > > 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 > > > [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 > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
