Thanks very much to John and Rob for your feedback. It seems my confusion stemmed around the statement:
"fanout writes the input record to all connected output streams before it tests for the number of streams at end-of-file." I interpreted that as FANOUT iterates over all output streams writing to them one-by-one, and then after it has done that, it then iterates over them all again testing via STREAMSTATE whether they are now at EOF. Based on Rob's feedback regarding the pipe actually outputting X,Y,X and an offline email I received from John, it seems that the actual behaviour is to iterate over each output stream writing to them one-by-one (and noting, at that time, whether they are at EOF). Once it has done that, it then checks the EOF count and either exits or goes around again. The reason this is important for me is because, over the past 6 months or so, I have been writing a pure Java implementation of CMS Pipelines. For the PIPE I posted earlier, I was finding that during performance testing, I might get 3 or 4 instances out of 10,000 invocations where the output was inconsistent (due to the timing issue I mentioned previously). But it seems that the problem isn't with my dispatcher behaving incorrectly but, rather, due to my misinterpretation of the FANOUT behaviour. Once I changed my FANOUT implementation to behave like the CMS one, I can run that pipe every single time with deterministic results. Thanks again for your feedback - and also for clarifying the actual behaviour - it is quite a challenge implementing things when I don't have a CMS system to test on :-) Cheers, Craig BTW, in case anyone is interested as to where I am up to with my Java implementation, I currently have the following features implemented: - The dispatcher is complete with one exception: stall detection. I have designed the stall detection mechanism, but have not yet implemented it. - Single- and multi-stream pipelines are fully supported. - Callpipe has been implemented and works well (but probably needs a little bit more testing). Addpipe has been designed but not yet implemented. - The dispatcher has the ability to generate events, which can be "listened to". Eventually, this mechanism will be used to implement RUNPIPE EVENTS. - Full support for MSGLEVEL, TRACE, STAGESEP, LISTCMD, LISTERR, et al (at both the pipe and stage level) - While I have done a little performance tuning, I have been very conscious of throughput during the whole design and development process. - These stages have been implemented: < > >> ABBREV ADDRDW AGGRC BETWEEN BUFFER CHANGE CHOP COMMAND CONSOLE COUNT DUPLICATE FANIN FANINANY FANOUT GATE HOLE HOSTID HOSTNAME LITERAL LOCATE NLOCATE NOEOFBACK NOT QUERY REVERSE SPECS SPLIT STEM STRLITERAL TAKE - My number one goal has been backward compatibility, so as much as possible (with the obvious CMS and EBCDIC differences notwithstanding), I have tried to make sure that the behaviour for the stages is completely faithful to the original.
