> Now this might be "interesting" to play around with for an uber geek. > Have a REXX exec running under a z/OS UNIX shell via telnet (not the TSO > OMVS command). The z/OS UNIX shell was invoked via a "specialized" > telnet client written especially for the following functionality. The > REXX exec does an ADDRESS TSO to run a REXX program which invokes an APF > authorized command processor. This command processor sets up an SVC > subsystem screening environment to "trap" all the TSO terminal related > SVCs. The REXX exec then sets up and invokes ISPF. The SVC screening > code sends information back to the z/OS UNIX shell, which basically just > goes back to that specialized telnet client. The telnet client uses the > information to create a 3270 like display (using curses, QT, > something-else). This is likely complicated and stupid to do. But it > seems to me that conceptually, this could effectively "get around" the 8 > user TSO limit without actually violating the licence. HOWERVER, I have > not read the z/OS.e license, nor am I a lawyer!
There are several products that do essentially that already and it is a whole lot more complex and difficult than you might imagine. But you have boiled down the logic pretty well. Products like this were intended to deal with situations where TSO is not available at all, e.g. in recovery situations where TCAS isn't up or can't come up for some reason. They existed long before z/OS.e was even a glint in some marketeer's eye. And since a couple of our products have been explicitly mentioned by others in this thread, please take the following as an explanation only. I am NOT trying to make a marketing pitch here. Hit delete now or read on. Our MAINVIEW Alternate Access product can run completely without VTAM or TSO. This product and similar offerings from our competitors all end up running the real TSO TMP in either a STC or batch address space, pretty much as John outlined above. For practical purposes it is TSO and it can do anything that you can do under a real TSO session. But again, it's not intended to replace TSO and I'm not sure what BMC's position would be in licensing it for that purpose on z/OS.e. IANAL but I would be surprised if we supported that. I would guess IBM wouldn't be too happy with that arrangement either. We also have a product called System Explorer for z/OS that is a full-function GUI replacement for a specific set of TSO, ISPF and SDSF functionality. It provides comparable functionality to SDSF and the main ISPF functions in options 1-3. It has browse, edit, job submission, dataset management, copy, search, compare, etc. Our intent was to open those services up to a more modern application development audience. This product runs in a multi user server address space without any TSO, ISPF or SDSF involvement at all. It is not a screen scraper or SVC screener at all. We believe it is within both the spirit (new workloads) and the letter of the z/OS.e T's and C's. CC (MAINVIEW Architect) ---------------------------------------------------------------------- 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
