On Sat, 19 Jan 2008 12:04:03 -0600, Paul Gilmartin <[EMAIL PROTECTED]> wrote:
>On Thu, 17 Jan 2008 00:15:31 -0600, Tony Harminc wrote: >> >>Then you write a REXX command environment handler (call it LINDYTSO or >>something, or even TSO if you want to be confusing; you can even make it the >>default), ATTACH each TSO command passing it a CPPL that you have set up, >>WAIT for it, and DETACH it. You have reinvented the TMP, sort of. IBM used >>to document how to write your own TMP, but withdrew (made OCO) the >>information needed in the 1980s. After all, why would any customer want to >>write their own replacement for IBM's fine IKJEFT01? >> >z/OS did much of this for us (including "TSO if you want to be confusing") >at v1r4: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB630/CHANGES Well, yes - this is BPXWRxxx. But it uses something like the second approach that I suggested: it fires up a real TMP in another address space, and sends the command(s) to that. Whether it uses standard UNIX pipes, I don't know, but that sounds like a Bill Schoenish thing to do. >It works for most authorized commands. But the TSO terminal interaction >design restrictions persist. For example, I have been unable to get >RECEIVE to work in that environment, presumably because of the DSN >prompt that must be answered. Can anyone else solve this? I imagine it's more a case of running a batch TMP. You should be able to send and receive command input and output, but I would guess that a command trying to prompt would get a nasty RC from GETLINE or PUTGET, and give up. One could probably catch the TGET/TPUT using SVC Screening in an initial jobstep task before invoking the TMP, but even then there would probably be some pretty ugly fiddling needed to make the TMP believe there was a terminal attached. Lindy's initial question was about the possibility of building a full screen REXX debugger by (among other things) replacing the REXX I/O routines. I imagine the UNIX REXX environment has already used the replaceable I/O routine addresses, so you would have to steal them (probably after initializing the UNIX REXX environment), and hope that there isn't too much checking going on in the UNIX REXX interface. This is all just another example of IBM's OCO madness taken to extremes. Not only is the code itself hidden from customers who might want to understand how it works, or fix or improve it, but the very design of TSO/E and its REXX interface is hidden, so that implementing such reasonable things as you and Lindy would like to do is made extremely difficult. People like Bill Schoen have, to their credit, done as much as possible to work around the nonsense without breaking the rules, with the Tools & Toys packages and such, and getting UNIX REXX into base z/OS is a great achievement. But even that code is OCO. IBM has in the past Open Sourced some previously OCO code like the OS/2 JFS, and OO REXX, presumably because they became unsaleable. Maybe it's time to Open Source TSO/E... Tony H. ---------------------------------------------------------------------- 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
