At the last conference I attended, the Unix Systems Services table was used for serving Guinness, and was one of the busiest tables.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dick Bond Sent: April 12, 2012 4:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: 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=/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 > ---------------------------------------------------------------------- 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
