Sergio > We have here a lot of EXEC's that is used from VM OPERATOR to display, > activate, deactivate lines from VTAM.
Ed Gould has opened up the possibility that you might consider changing your operational environment and changing the REXX Clists you use in order to achieve what you really want to do. The appropriate environment for managing automation - and hence obviously entering REXX Clists with any sort of command not only VTAM commands - from the IBM stable of products is NetView. Indeed NetView in its original manifestation as NOSP in the late 1970s was specifically designed for the entry of VTAM commands in order to assist with complex and tedious sequences required to manage VTAM and NCP. NOSP developed into NCCF and NCCF, being also an application-enabling environment, developed into NetView together with a few of the applications so enabled.[1] It is still the NCCF component of NetView, rebranded as the "command facility", which provides for the entry of commands. But complementary to the entry of commands is the ability to analyse the messages returned by the commands and act on them by entering further commands and so on. This is a function which eventually this "command facility" supported and then the choice - generally not a difficult choice - became available to use REXX as a Clist language with all the same capabilities as the specifically NCCF/NetView Clist language which was used before, a Clist language based very approximately on VM EXEC. It's this ability to analyse the results of having entered a command I wanted to bring to your attention. What I mentioned above was the possibility to handle messages *solicited* by command entry. In addition it is possible to handle messages which have not been *solicited* by command entry, *unsolicited* messages, by the agency of a "message automation table". I retained a presentation from back in 1991 of how I used to use these functions in order to achieve totally "silent" IPLs of my test/education systems, so "silent" that my colleagues insisted I set up a system of "what's going on" messages to assure them that something was happening - but that's another story. > What We need, is execute this commands by operators under Master console of > Z/OS. I just checked this presentation in order to assure myself about the customisation needed in order to ensure that the MVS system consoles were available for entry of Clists which were to be executed in a NetView environment. > We don't mentioned before, that what want, is execute a REXX from MASTER > Operator Console for ZOS. Actually, you did! > We need now, transfer this EXEC's for run under TSO. So deciding that you needed to use TSO was already an assumption too far! > We are migrating our environment from Z/VM, and Z/VSE to Z/OS. Ideally, you would already be using NetView with z/VM. To think, just about my first presentation activity in 1985 when I started teaching full-time was to teach NCCF in a VM environment! - [1] And supposedly too difficult a job for the poor lambs of system programmers to integrate - hence NetView with its "one size fits all" combination of products! OK, I used to teach how to do it so they could have been taking away my livelihood! - Chris Mason On Fri, 8 Jul 2011 14:54:21 -0300, Sérgio Lima Costa <[email protected]> wrote: >Hello List, > >We are migrating our environment from Z/VM , and Z/VSE to Z/OS. >We have here a lot of EXEC's that is used from VM OPERATOR to display, >activate, deactivate lines from VTAM. >We need now, transfer this EXEC's for run under TSO . >What We need, is execute this comands by operators unde Master console of ZOS. >Is possible execute this there? >Need write a PROC with a name ? , then the operator give the S XXXXX , where >XXXXX is the name o four PROC / REXX . > >Sergio Lima Costa ---------------------------------------------------------------------- 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
