On 2016-09-02 17:05, Paul Gilmartin wrote: > > But is CMS DFSORT sufficiently Pipelines-friendly that this can be > done without resorting to an intermediate temporary file? > OK. Answering my own question. I RTFM (Author's Edition). There is a DFSORT stage. I assume that for large inputs it uses its own invisible temporary files.
o Strange. It avoids SORTIN and SORTOUT, using the E15 and E35 exits instead. o Even stranger. The user must offset key positions by 4 bytes to account for RDWs. I'd expect DFSORT to handle this internally. Does it just regard the RDW as data? I'm trying to imagine all the ways a delaying stage might cause a stall. Can one run two DFSORT stages in parallel? -- gil
