On Thu, 10 Sep 2009 11:07:36 -0500, Chris Mason <chrisma...@belgacom.net> wrote:
>... >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? Caveat: My introduction to NetView was to upgrade R1 to R2 in 1989 and we did not have any automation in place to be converted. My memory is a bit shaky and I didn't need to apply anything I was reading, but I vaguely remember the description of a rudimentary form of automation described that went a little bit beyond what Chris described. I think a clist named the same as a message id would be invoked automatically when the message was issued. (There may have been a table specifying the automated message. I don't remember. If so, it was a far cry from the automation table introduced in R2.) The description of that first NetView release describes "Improvement of the capability to drive NetView CLISTs based on application messages (such as VTAM, CICS, and IMS)" but NetView did not use the SSI until release 2 so I'm not sure how it saw the non-VTAM messages. (VTAM message would have been presented to NetView across the Program Operator Interface.) >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. Anything sitting in the list of SSIs or invoked via MPF would have been able to be cleverer than that original NetView. I have no idea what technique TSSO used to get the messages it automated, but it would be hard not to be cleverer than that NetView technique. >... >[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. The API in this case would have been to define TSSO as a "command" in NetView's command table definitions and to have TSSO access NetView's command parameter control blocks when invoked. I'm not sure what this would have achieved, though. It would be interesting to see the data flow though NetView and TSSO when used this way. I'm probably envisioning the wrong flow. Pat O'Keefe ---------------------------------------------------------------------- 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
