On Tue, 3 Feb 2015 12:35:16 -0500, Tony Harminc wrote: > >> "address TSO" from a Rexx EXEC spawn()ed under Unix System Services >> runs the TMP in a separate address space, perhaps more like a job step >> task; certainly more roundabout. > >This is an elegant approach; the problem is that you don't know with >certainty what output comes from what command. If you are ATTACHing >commands yourself, you know where the boundaries lie. > >Effectively you have to screen-scrape (line-scrape?) the output >looking for READY or whatever the subcommand prompt may be. You also > Not really. No more than when you OUTTRAP to a stem you need to scrape the trapped output looking for READY. (But I suspect the TSO host command interface does something of the sort.)
It's a programming interface, not a terminal interface. You can run a command and direct its output to a data set, not much more. >want to avoid being prompted for input, whether unavoidably as with >RECEIVE, or in the case of an error, or have an even more complex and > Unfortunately true. I can't really make RECEIVE work in that configuration. RECEIVE ought to provide a "no prompt" mode where everything is supplied in command arguments. >error prone scheme of parsing and replying to prompts. > And I got an ABEND in a batch job when I allocated DD SYSTSPRT to a UNIX file. PMR. APAR. PRS. Something about crossed-up keys. That sort of thing shouldn't be tolerated. (I had something similar (twice) when I allocated HLASM SYSLIB to a mixture of PDS and UNIX files. That one they fixed, both times. The design is not robust. If you break it, they don't feel they need to fix it. --gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
