I can think of a couple other solutions using out-of-the-box methods, but neither is as clean as what you're proposing. You'd need a minimum number of subsystem routines - JCL processing, allocation, open and close, and maybe another couple. At OPEN time, issue OPENs for the related files, update the DCB (or ACB) with appropriate info including your PUT/WRITE interface address, and any data that the original program may need, like LRECL, RECFM. It would have to recognize move and locate modes, and possibly have to build a buffer pool in case the program wants to do a freepool. You could almost ignore exit processing (have to think about that one). As you suggest, on the output side, the two (or more?) files could be QSAM or VSAM. The entire process could be as simple or as complex as you want. Possible additions include filtering one of the output files for certain records or for every nth record, or connecting to an IP port for one of the outputs, or sending filtered data to the console.
OK - wait - I'm supposed to be working here, not daydreaming. <snip> The TEE subsystem is inspired(?) by the UNIX tee command. The tee command reads its "stdin" and sends it to a named file and its "stdout". The main use is to be able to read the stdout on the terminal and log it to a file. I use it simiar to: "make | tee make.listing" which lets me keep the make output in a file and watch it also. So I considered that something similar for JCL might be useful. I thought of something like: //SYSPRINT DD SUBSYS=(TEE,'FILE,SYSOUT') //FILE DD DSN=OUTPUT.FILE,DISP=(NEW,CATLG), ... //SYSOUT DD SYSOUT=* The program opens SYSPRINT. The TEE subsystem then opens DDs FILE and SYSOUT. Every record written to SYSPRINT also goes to FILE and SYSOUT. Why do this? In order to write the output to a file while, at the same time, being able to see what is being written by using SDSF. Our programmers often write reports to SYSOUT in order to monitor them, but then need to use SDSF to put them into a disk file. An advanced implementation might want to be able to write to VSAM (KSDS or ESDS) instead of just writing to a sequential file. Or use this to "fan out" a dataset so that a GDG version is written to tape whereas a non-GDG version is written to disk. </snip> ---------------------------------------------------------------------- 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
