Chris, I don't really have any trouble keeping up. While I could have done the search on the manuals, I would not have caught the significance without spending a fair amount of time ploughing through the manuals. Since FSS is a valid concept and used as an acronym. It would seem that the Terminology folks have "missed one".
I do find it interesting regarding the automatic behavior of FSS regardless what is specified. As to the spell checker, I try not to let spelling interfere with my conversations. I never noticed any difference while reading Shakespeare, and I usually don't notice spelling errors unless my brain refuses to properly interpret. Cheers, Rob On Tue, Feb 15, 2011 at 1:49 AM, Chris Mason <chrisma...@belgacom.net>wrote: > Rob > > A simple search in the manuals most likely to indulge the topic would > quickly > find your answer: > > z/OS V1R12 Communications Server SNA Network Implementation Guide, SC31- > 8777-10 (NIG) > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B5A0/ > > FSS: 1 hit > USS: 25 hits > > z/OS V1R12 Communications Server SNA Resource Definition Reference, SC31- > 8778-11 (RDR) > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B6A0/ > > FSS: 17 hits > USS: 99 hits > > Those statistics do not tell the whole story but they support the statement > that the VTAM systems programmer needs to think about setting up some > customisation in order to exploit the many capabilities related to the > topic > of "Unformatted System Services" whereas, by its very nature, "Formatted > System Services" is SNA business-as-usual protocols and formats and no > customisation is involved. It's not a property of the contrasting names but > any > VTAM systems programmer knows that the whole purpose of "Unformatted > System Services" is to convert from text strings convenient for human end > users to the same request units that correspond to what is described > as "Formatted System Services". In other words "Unformatted System > Services" is a layer "on top", as it were, of "Formatted System Services". > > Note that the single "hit" in the NIG is actually a sample definition that > happens to be SSCPFM=FSS while the 17 "hits" in the RDR are descriptions of > the definition statement operand SSCPFM which has FSS as one of the > possible values, the default in fact. When SSCPFM has another value, always > with USS as the initial part of the value, it indicates to VTAM what > character > string rules will apply to the "Unformatted System Services" data. > > Actually, VTAM really only needs to be told about those character string > rules. > Since there is a bit in the request header which indicates whether a > request > unit on the LU to SSCP (VTAM) flow is "formatted" - that is, can be parsed > according to the structure of the bits and bytes in the request unit data - > or > is not "formatted", if VTAM receives a "formatted" request, it quietly > assumes > SSCPFM=FSS even if some other value, starting with USS, is actually > specified. > > I hope you were keeping up at the back! > > Anyhow thanks for prompting me to get my thoughts on the subject > organised. As you may have noticed whenever VTAM definition statements are > offered in a post, I usually take the opportunity to "clean them up". I > realise > now that there really is no rôle for SSCPFM=FSS and so in future I will > suggest > nobody ever bothers to specify it. It must be getting on for 35 years since > I've known that operand with this value without realising quite how > pointless it > is! > > Regarding "terminology", FSS, being business-as-usual, just doesn't need > anything like the volume of references that USS does given the wealth of > customisation possibilities which it has accrued over the years. > > Which takes me to another pair of manuals where you will find a number of > references to USS: > > z/OS V1R12 Communications Server IP Configuration Guide, SC31-8775-17 (CG) > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B3A0/ > > z/OS V1R12 Communications Server IP Configuration Reference, SC31-8776-18 > (CR) > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B4A0/ > > In these manuals there are no "hits" for FSS but a number for USS. This is > because the VTAM facility has been taken on by the TN3270E server so that > the "look and feel" for the 3270 emulator user converting to TELNET > (TN3270) > from a pure SNA connection need not change - or need change only to be > enhanced since the variable information which can be presented in the USS > messages can include IP-related information. > > There are no "hits" for FSS since, in effect, the TN3270 solicitor panel is > the > approximate equivalent of "Formatted System Services". > > If the designer behind the TN3270E RFCs had been on his toes, he might have > allowed an even more enhanced function but he regrettably removed one of > the most useful aspects of the USS function in not permitting USS messages > to appear while a session was in place.[1] What a lost opportunity - all > down > to ignorance of SNA's capabilities, an ignorance of which in those who > should > have known better I am perpetually reminded ... > > Chris Mason > > [1] Why? - the curious are asking. Because all those variables so helpful > for > problem determination while calling the "help desk" can be presented in an > USS > 5 message in a pure SNA environment but not with the unnecessarily > restrictive design of RFC 2355. > > P.S. You may have noticed that my spelling checker has been at work again. > > On Mon, 14 Feb 2011 20:59:20 -0500, Rob Schramm > <rob.schr...@gmail.com> wrote: > > >I have been trading e-mails with the Terminology folks and reading the > >Terminology page and noticed the formatted system service which made me > >wonder: > > > >If unformatted system service is represented by the acronym USS. Why is > >there no FSS for formatted system service? Or is the FSS acronym already > in > >use but neglected by the Terminology folks? > > > >Rob Schramm > > ---------------------------------------------------------------------- > 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 > -- Rob Schramm Senior Systems Engineer w: 513.305.6224 ---------------------------------------------------------------------- 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
