>What __might__ be nice. And __would__ prove TSO is not moribund. Would >be to have a TSO capability via native TCP/IP. Unfortunately, it appears that >the 3270 terminal architecture is so imbedded into TSO that such would be >very difficult. Which translates to expensive and time consuming. Better to >replace TSO entirely. Which RD/z (or whatever its called now) is trying to do. >Unfortunately, compared to TSO and ISPF, RD/z is horribly expensive. Like >most "advanced" things on z/OS. <insert usual complaint about the cost of >z/OS software here>
"Native TCP/IP" may be at the wrong level. TN3270 runs over "Native TCP/IP" and provides the protocol for positioning output data, identifying input data, standardizing screen sizes in terms of character and line counts, etc. "Native TCP/IP" would only provide message traffic, but no formatting. Yet, any TSO replacement that expects to support the many existing ISPF and other 3270-style data displays would have to still present data in a very similar manner. Also,I don't believe the issue is so much with the VTAM side of things, either. VTAM can support full duplex just fine. Based on observation, I believe TSO applications are designed so that they each expect to have full control of the display. Actually, after thinking about it a bit, the line-mode (pre SPF) applications are entirely half-duplex functions. Following in that design, ISPF does not allow subtasks to run (AFAIR) when the application is waiting for input. Thus, having multiple tasks performing separate functions and updating different parts of the display image is not supported in TSO. That is not to say that such functions cannot be supported. Many years ago, when I worked at a TCAM shop, and microfiche of much of the IBM source code was still available, my employer had a requirement to access TSO on multiple systems using a single terminal. TCAM had a restriction in its design of TSO that only allowed terminals to use TSO on the same system that owned the terminal. I dug into the code and found that all of the key routines for TSO had common code, except when they had to work specifically with the access method. So, sprinkled through IBM's code were tests of a bit in a control block to see if the user was using TCAM or VTAM. Since we didn't have VTAM, I stole each of those branch points, and inserted my own code. The end result was that I had effectively rewritten TSO as a straight TCAM application, which did not have the afore-mentioned limitation of which systems it could run on. Having been inside that code, I believe an enterprising person or group could, with relative ease (perhaps depending on skill and determination) build code using the former TCAM intercepts, and redesign some of the TSO functions to support whatever design they needed. Digging through long-forgotten memory, some of those points to examine are address space create, address space termination, plus SVC's 93 and 94. For direct TCPIP use, the application would also have to listen on a socket, accept an initial contact and start another address space, which would run the main TSO functions for that user (LOGON, input, output, etc). Now, the other end of the issue is what the user has for their portal. Is it using a 3270 emulator? Is it expecting HTML? What about JAVA or something else? The display function and the TSO emulator have to be compatible. ---------------------------------------------------------------------- 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
