On Mon, Nov 21, 2011 at 14:02, John Gilmore <johnwgilmore0...@gmail.com>wrote:
> > > The use of the SORT to do this job seems to me to be much akin to > using a piledriver to set a ten-penny nail., and I should be > interested to know why you sought a canned solution to a problem of > this sort. > Though clearly the programming effort to write my own code to do this is trivial, the reason for wanting a "canned solution" is to avoid all the "business rules and procedures" associated with writing "custom code". If I roll my own, it has to go through the whole QA process, and distributed to various geographically diverse MVS systems where I need this capability. DFSORT is available right now. It's been debugged, it's been accepted, it's in production, now. If DFSORT can do what I need, that's perfect. The cycles to run DFSORT for this are less expensive than my and other people's time to properly support it. If there's another "out-of-the-box" solution, I'm all ears. i.e. my cms/tso pipelines solution suggested in my original post. (But I'm note sure we have PIPELINES on all our MVS systems.) I'm also a big believer in using existing wheels. Why do I want to write a program that already does what another, already available one does? The reason I need this capability is so I can extract a subset of records from one or more tapes in various geographically diverse MVS sites, send that data to another MVS site that has USS and do some stuff with it there. I could just copy the entire tape across the country/globe, but I do have some limits regarding wasted bandwidth/cycles. :-) It's a trade-off/balancing act. Cheers ---------------------------------------------------------------------- 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
