You're not overlooking anything, Glenn. The design choice is whether to write the record to the driver before or after it is written and consumed on the primary output. If you write it before, you will see records that are not consumed, but in the "right" order; if you write after, you see only what was consumed, but if the following stages do not delay the record, the order will be "reversed".
j. 2009/1/7 Glenn Knickerbocker <[email protected]>: > EOFBACK CONS and now EOFBACK WARP is convenient for tracking records > through a pipeline without reading extra input records, but it creates a > weird timing problem: Since the record isn't written to the driver > until after it's released, you wind up following the record upstream > rather than downstream. > > PIPE literal x|eofback cons|pad 2 x|eofback cons|pad 3 x|cons > xxx > xx > x > > I wrote myself a little COLLECT REXX to do it the old-fashioned way > using FANOUT|COPY|SYNCH|FANINANY, but of course SYNCH doesn't terminate > until it actually fails to write a record, so it still reads one extra > record (and each SYNCH further upstream reads one more). > > pipe literal 1 2 3|split|a:collect|pad 2 x|a:|pad 3 y|take 1|a:|cons > 1 > 1x > 1xy > 2 > 2x > 3 > > Am I overlooking a way to get the records in the right order without any > extra? > > ¬R http://users.bestweb.net/~notr/xmas2008 >
