Cris

> Kindly define and differentiate these terms for me so I can return to knowing 
> what I don't know with peace of mind restored.

I'll be as "kind" as I can!

It's because this is an impossible task with the wanton disregard of 
abbreviation standards that I embarked upon what you quite rightly characterise 
as a "rant" but a thoroughly justified "rant" given the prevailing stupidity.

I hope this is not a disingenuous enquiry and you genuinely were not aware of 
the problem. If that is the case, you are in the same position as I assumed was 
possibly the case for Saurabh, and I can guide you aright.

First, take note of this post from an eminent IBM developer which I will quote 
in full for you:

<quote>

From: IBM Mainframe Discussion List On Behalf Of John Eells
Sent: Tuesday, July 28, 2009 11:54 AM

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.

</quote>

All appearances of this abbreviation in reference to z/OS UNIX System Services 
are incorrect whether the author is employed by IBM or not.

Why? - I hear you ask.

You just need to take a look into the PROFILE data set which Saurabh supplied 
to spot the dread three letters used within the name of the table used to 
assist the matter under discussion and which you quite correctly said needed 
additional information. The statement is the following:

  USSTCP USSYSA7

In hoping to make the matter of explaining Saurabh's problem easier I came up 
with my lettered questions. When I got to B it occurred to me that Saurabh's 
consciousness may have been so swamped by this misuse that he[1] assumed any 
reference to the dread three letters referred to z/OS UNIX System Services. 
Furthermore it seemed likely from his rather naive - I hope he'll excuse my 
saying so - approach to providing information - a D A,L and the whole PROFILE 
data set and some rather curious reference to definitions in other releases - 
that he may be dealing with a topic with which he had yet to become deeply 
familiar and that it was someone who had been "let go" who set up all these 
definitions and so actually could deal with the dichotomy - <rant> as the 
conceited idiots always try to excuse themselves by claiming is always possible 
</rant>. For such as you - assuming a genuine enquiry - it obviously is not! 
<rant> Will the conceited idiots ever accept this? No, of course no!
 t, their barely concealed agenda - when the obtuseness is not just pure 
stupidity - is to deny the existence of anything remotely connected to SNA 
</rant>.

So, I hear you ask further, how and when did this problem arise? In the 
mid-1970s IBM created SNA and supported it with VTAM in the S/360-legacy 
systems. For the benefit of human end-user SNA devices "Unformatted System 
Services" (USS) was set up as a component of VTAM in order to allow character 
strings to be entered which VTAM converted to session-initiation and 
session-termination requests (and a diagnostic facility). Sometime around 20 
years later IBM adds UNIX (not even UNIX-like but actually at the time the only 
official UNIX) capability to generic MVS (now z/OS). Eventually this component 
becomes branded as z/OS UNIX System Services.

The USS end-user assistance facility has been "ported" from the SNA side of 
Communications Server to the IP side of Communications Server so that TN3270 
users - (trying to) log(ging) onto TSO, for example - can have the same sort of 
environment with their TN3270 client emulator workstation as they had with 
their typically LAN-attached SNA emulator workstation.

It perhaps doesn't help in being able to make distinctions that at the heart of 
USS are commands - principally for the purposes of managing sessions - and 
messages - to welcome the end-user or to explain why he/she has made a mess of 
their session management attempts! This has led to some humorous 
misunderstandings in IBM-MAIN posts. <rant> Do the unspeakables care that such 
ambiguity is possible? Do they <unspeakable>! </rant>

At the point where the "MVS" UNIX component became branded as z/OS UNIX System 
Services, the rot set in. IBM took insufficient care with manuals in order to 
ensure that the dread three letters were *not* used in order to refer to the 
component rather than what is clear - by and large - from the "mainstream" 
manuals is supposed to be used, z/OS UNIX. The principal IBM authors somehow 
got to know the correct usage but the dread three letters crept into typically 
updates and sometimes got flushed out, presumably when the cat rustlers got 
wind of the errors.[2] Now of course, the occasional stray moggy is used as an 
excuse by the unspeakables as the excuse for their persistent misuse.

So, I hope that makes it all a bit clearer.

-

[1] It's when we can't be sure how we should refer to a contributor asking a 
not particularly well-honed question as "he" or "she" based on a name which 
offers most of us old lags no clues, that we are entitled to assume that they 
are likely to be relative novices and especially unable to deal with topics 
such as this. <rant> Not that such kind considerations are going to hold any 
sway over the unspeakables. </rant>

It may also be an indication of relative "newness" to the IBM environment that 
he (or she) uses the specialised verb "login" rather than the usual "logon" to 
phrase his/her Subject line.

[2] I checked some of these instances in certain manuals over a number of 
releases. You can almost hear knuckles being rapped!

-

Chris Mason

On Fri, 5 Aug 2011 13:19:34 -0700, Cris Hernandez #9 <hernandez...@yahoo.com> 
wrote:

>When it comes to unix (or winders), I really don't mind being the village 
>idiot, because at least I know what I don't know, or at least I thought so 
>until I read this rant.  A lot of my manuals refer to (what I call) "mainframe 
>unix" as OMVS and/or USS.  Not being a seasoned uniq, all these references are 
>synonymous to me.  Kindly define and differentiate these terms for me so I can 
>return to knowing what I don't know with peace of mind restored.
>>
>> [1] There are very many people in this list who misuse the term USS when 
>> they should be using the term z/OS UNIX or z/UNIX. I divide people into 
>> those who deliberately misuse the term, the conceited idiots, and those who 
>> are misled by the perpetual misuse by conceited idiots who should know 
>> better and are beyond the reach of reason. Those misled of course tend to be 
>> those who have recently become involved with z/OS who should be being 
>> assisted in their understanding of this complex topic but who are treated 
>> with disdain by the conceited idiots.
>>
>> For example, in trying to solve this problem, you may well be trying to 
>> examine the role of the USS table, its commands and messages, in trying to 
>> resolve your problem. You may well have become thoroughly confused over how 
>> this relates in any way with what you think you have learned is to what 
>> "USS" might refer, namely, and quite falsely, z/OS UNIX System Services. The 
>> conceited idiots are too thick to get their puny brains round this 
>> particular problem - or is that also an "issue"?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to