Isn't this an OS390 O/S?, if so, I'm not sure what SDSF REXX interfaces are supported.
I have developed some SDSF REXX code (sorry Ed Jaffe ). It does exactly what Tony is looking for. We have some Windows apps that talk back to Tivoli Workload Scheduler and all the output ends up in a Tivoli bucket started task with the output in a JES2 writer. The problem we had was linking some Windows task with the originating z/OS batch job. This is how we dealt with it: We read the Tivoli STC output and parse the writer output. This contains the original z/OS job name and any return code and failure information. We scrape this output and create a new job name that matches the originating job. The new output is printed using IEBGENER. We purge the writer output from the STC, so it won't be seen again. The job is picked up by our output manager (OMCS) and archived. It's clunky but it gives the end user the ability to look at the job with its original name. On Sat, Aug 29, 2020 at 11:29 AM Steve Smith <[email protected]> wrote: > I suggest the original output be directed to a regular file, which would > make reading it for the split much simpler. If that's not an allowed > change, oh well (or ow, hell?). > > I think I might suggest to the client that I could replace the existing > vendor product for say, 50% of the cost. That should give you the > motivation to find the time to write it. > > sas > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
