First of all I should say thank you to Gerhard Postpischil for providing some helpful background as to what TSSO is all about.
Gerhard has sent me a private message expressing umbrage over my post and accusing me of not reading his post - the usual symptom of someone who has actually failed to read the post about which he/she is commenting! In case there are others who haven't understood, I'd better spell it out. The relative cost of NetView/NCCF and TSSO are not relevant. What is relevant is function. I did *not* - repeat ***not*** - intend to imply that NCCF - and early NetView - had automation capabilities comparable to those TSSO appears to have had. That is what that "cost comparison" comment implies - but Gerhard has not to be able to see. In the days of NCCF - and I think NOSP before it - and the first release of NetView, a semi-automation capability existed after the clist language was introduced. I describe it as "semi-automation" in that the operator had to keep an eye out for unsolicited messages betokening a problem. He/she then had to enter the name of the clist and commands could be issued - with name substitution from clist operands. If any delay was necessary, the operator could be instructed for which solicited messages to look out and what new clist commands to enter. Crude or what? It would appear that during these dark days, TSSO offered a cleverer way which included actually "trapping" messages and entering commands fashioned by the information "trapped" - if I have understood the TSSO of the early '80s correctly. Turning to my post - *in full* - I used the crucial word "insist", the significance of which escaped Gerhard. Clearly TSSO could be used independently of this NCCF product with its hobbled automation capabilities [1]. TSSO is described as allowing itself to be invoked from NCCF/NetView as a "command processor", that is, TSSO has been extended to use one of the APIs which characterised NCCF - and the "command facility" component of NetView - as an "enabling" environment. Thus TSSO could be used even where the installation's style was to "insist" or "require" that *all* automation be performed from within NCCF or NetView. The "short period" referred to the time from TSSO being available as an NCCF "command processor" to the time when everything that TSSO could do could also be done using NetView's native functions which - if my presentation notes are to be believed - happened with NetView V1R2. Actually, it's possible that period was not so "short". It could be something like 1980 to 1987, my guessed dates for NCCF (V1R2?) offering "command processors" to NetView V1R2. I hope that clears up any confusion - or maybe just adds to it! Chris Mason [1] Fortunately I retain my presentations on the topic of NetView clists and I see that a level of automation which I believe can be compared to that possible with TSSO appears in NetView V1R2 with the introduction of the "message automation table". Since this is not NetView V1R1, I have to "copy" the "hobbled" adjective to NetView from NCCF. On Wed, 9 Sep 2009 19:32:04 -0500, Chris Mason <chrisma...@belgacom.net> wrote: >I thought I hadn't been as stupid as is here implied! > >> if you insist on doing all your automation though NetView's "command >facility" > >is what I said before the part quoted. > >Some royal misrepresentation through selective quoting going on here! > >There is a lot - did I say "a lot"? - to be said for quoting the *whole* of the >referenced post even when picking out some parts - as I always do. > >Chris Mason > >On Wed, 9 Sep 2009 20:05:35 -0400, Gerhard Postpischil ><gerh...@valley.net> wrote: > >>Chris Mason wrote: >>> comprehensive functions for my "silent running" automation. In other words >>> there may have been a short period in the history of NCCF/NetView when >>> TSSO offered the cleverest way - maybe the only way - decently to >>> automate MVS, that is, better than using the internal reader for commands >>> and a "wait" program. >> >>The first version of TSSO appeared not too long after TSO. I am >>not certain who the original author was, but recall seeing Bill >>Godfrey's name in the documentation. That version allowed the >>operators to issue (some) TSO commands from a console. In the >>mid or late seventies, Marc Share at Bell Labs presented an >>updated version that provided the capability to intercept >>console messages, and take some action (message, OS command, >>etc.); the nice part was the extraction by position or word >>count from the message, and insertion into an MVS or TSO >>command. When I was at AMS, and several later centers, I used >>this to automate just about everything possible (e.g., VTAM line >>and terminal error recovery, deletion of unwanted messages, >>etc.). IIRC, the early versions of NETVIEW/NCCF were a >>chargeable item, so TSSO was it. And it certainly was more >>flexible than (the early) linked exits, because it was table >>driven and the tables could be reloaded on the fly. >> >>Gerhard Postpischil >>Bradford, VT ---------------------------------------------------------------------- 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
