Radoslaw > I have to give away deep secret: I have IBM documentation, ...
The "secret" about having documentation is to have the wit to understand what is written. In case this is some snide comment on my having provided an URL as reference, this is actually just my usual way to ensure that anyone else - not necessarily the addressed contributor - has ready access to the matter under discussion. > Well. I don't know if any of IBM started tasks use any of FFST calls. There is no necessary relationship between "started tasks" and applications using FFST. Perhaps you mean the regular "underlying", typically "enabling", applications which tend to be run as "started tasks". > IBM never ever asked me for anything related to FFST. I'm rather of the opinion IBM support should be asking for FFST-generated data for any products which include FFST "probes". However I find two aspects to this matter interesting: 1. The sole manual - as befits its title in fact - contains no description of the API used to specify an FFST call - or "probe". However, taking a command example in an APAR I found - a rather revealing one! - while researching this topic, I see that "probes" can be qualified by a VENDOR field. This implies that "vendors" - other than IBM - can use FFST. So where is the API described to which "vendors" have access? MODIFY FFST,ACTION=DISABLE,PROBEID=DSIABN01,VENDOR=IBM 2. I have never been in charge of a production system but I have worked closely in a consultant's role with those who are. I'm sure I have heard more than once - typically associated with a sigh - that, in order to have a problem logged with IBM support, IBM support will make no effort actually to understand the problem until they have received a dump with all the hassle that entails. Am I just being fanciful or is it not to streamline the process of collecting diagnostic information that FFST was created? So why <manifold expletives deleted> is IBM support *not* asking for FFST-generated information for those products which support FFST - reduced to the two Communications Server products I believe now that NetView has dropped its sole "probe" (APAR OW54489) - and why <yet more expletives deleted> is IBM development not using this tool in many more products? I could also ask, if any of the "vendor" representatives in the list are still reading, why they are not agitating to use FFST? Or perhaps they are - or perhaps they used to before IBM put them off the idea for whatever reason. - > 1. You don't know what I would love or not. As a documented anti-SNA/VTAM bigot, that is a very easy conclusion to reach. Perhaps some of the intended sense has been lost in translation to Polish. > 2. I see this 2- or 3-entries list everytime I close FFST. One is TCPIP (usually closed long time before) and the second is "something" with SNA in the name: > TCP z/OS CS IP > VTAM z/OS CS SNA > CSM z/OS CS SNA In case this is a genuine statement of puzzlement rather than yet more sarcasm, I'll assume the former. "TCP" refers to the IP component of Communications Server - a rather stupid abbreviation IMNSHO since it could just as easily have been simply IP or if necessarily alphabetic TCPIP - of which I don't really approve - or if somehow necessarily constrained to 4 characters, TCIP - although TUIP would make more sense as a compressed abbreviation. "VTAM" refers to the SNA component of Communications Server. Why there should be any difficulty understanding this, the "second" entry, totally defeats any speculation! RS must have been having a particularly bad day - or is this just some unconscious manifestation of the denied hate. "CSM" refers to the "Communications Storage Manager" component of Communications Server of which little is said although CSM does have a document all to itself: z/OS Communications Server Communications Storage Manager (CSM) Guide: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1g220/ I guess if I wanted to try to be charitable, I could assume that there had been a small rush of blood and, where "second" appeared, "third" should have been written. The reason CSM is associated with the SNA component of Communications Server is that it is the "VTAM" compartment of the portmanteau product which is tasked with some common I/O used by both the SNA-based logic and the IP- based logic. This is not unconnected with some interface definitions finding themselves relying on that strange VTAMLST entity, the TRLE. You may indeed find it beneficial to become familiar with the DISPLAY NET,CSM and DISPLAY NET,CSMUSE commands in order better to understand what is happening in your system. - > However the system works quite fine without FFST. > I'm not enemy of FFST, I don't want to switch it off, I don't want to say it is useless. I simply DON'T KNOW what it is for. Then asked. As has already been very well established, we - should - all by now know what FFST is for. With even the most cursory understanding, it is evident it has nothing to do with stopping problems with the system - what tosh! What is clear is that, if IBM support is too dumb to require output from this tool when problems are reported, it is more fool them. I can't say it is more fool the systems programmers for not supplying the information if IBM support doesn't ask for it. I would like to suggest that the cost of support is higher because this potentially useful tool is *not* used. If this is so, IBM support should be marked down in those "How well - or otherwise - did we do in the last (period)?" surveys until IBM support pulls its socks up - and IBM development retrieves this baby from the bathwater. I would also be interested where the FFST API is described or there is no sense in the VENDOR field in FFST if it is always condemned to be "IBM"! - Chris Mason On Tue, 19 Apr 2011 12:54:08 +0200, R.S. <[email protected]> wrote: >W dniu 2011-04-19 10:30, Chris Mason pisze: >> This is a pair of questions asked by Radoslaw Skorupka in the RACF-L list as a >> musing resulting from a question being asked about FFST and SAF. >> >> It seems pointless to have the discussion continued in the RACF-L list which >> was actually the wrong place to be asking the original question anyhow. >> >> - >> >> Radoslaw >> >>> What is FFST for? >>> What would I loose without it? >> >> The first is quite adequately covered by Chapter 1 of the FFST Operations >> Guide, SC31-8604-01: >> >> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/F0Z0BK01 > >I have to give away deep secret: I have IBM documentation, including >FFST. I even read some parts of it. So my questions do not come from >lack of this knowledge. I also know what FFST stands for. And despite of >the above I asked the questions. > > >> The second, assumed to be "What would I lose without it?", is answered by >> whether or not you use products which use FFST calls and whether or not you >> would lose your good relationship with IBM support if you cannot supply FFST >> output when you have a problem with any such products. > >Well. I don't know if any of IBM started tasks use any of FFST calls. >I'm pretty sure, that none of my applications (understood as business >application) do it. IBM never ever asked me for anything related to FFST. > > >> Of course, one >> candidate - of possibly very few - is the IP component of Communications >> Server and also - although I know you would so dearly love not to have to use >> it - the SNA component of Communications Server! > >1. You don't know what I would love or not. >I use SNA and neither love or hate it. For me it as senseless as >love/hate of DD statement or ESCON plug. > >2. I see this 2- or 3-entries list everytime I close FFST. One is TCPIP >(usually closed long time before) and the second is "something" with SNA >in the name: >TCP z/OS CS IP >VTAM z/OS CS SNA >CSM z/OS CS SNA > >However the system works quite fine without FFST. > > >To be understood correctly: >I'm not enemy of FFST, I don't want to switch it off, I don't want to >say it is useless. I simply DON'T KNOW what it is for. Then asked. > >-- >Radoslaw Skorupka >Lodz, Poland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
