I have a Pipe, fragment below, that has several CMS command stages, each one processing commands built from the responses of the prior command. Eventually, there is a SORT. This Pipe was failing with an immediate RC=70. I tried inserting some '| >> diag file d' stages at various points and, unexpectedly, the program ran to a successful completion. If I took out the diagnostic writes, it failed again. My next try was to remove all diagnostic writes except for the first. Once again, success. I replaced the write with an Elastic stage, which resulted in a failure. Replacing the Elastic with a Copy resulted in success. Next I tried moving the Copy to different locations. It succeeded if the Copy was placed anywhere preceding the Sort. This includes putting it as the second stage, following the query limits, and putting it immediately before the Sort. Anywhere following the Sort resulted in the immediate RC=70.
In this Pipe, the primary stream builds records that eventually become the Detail records in a Lookup (really a Not Lookup, I am only interested in the unmatched details). The Lookup, which is several stages following the Sort, is the only stage in the that has a secondary input defined. The secondary output is not connected. There is no record delay in the stream that provides the Master records. I have two questions: 1. Why is the Copy or other stage required? I would have thought that the Sort stage would be sufficient as a consumer of records. After all, it cannot buffer the records without consuming them, can it? 2. Why did the diagnostic write, the >>, cause the Pipe to succeed? Does >> write and consume a record before sending it down the primary output stream? Pipe fragment follows: 'PIPE (end \)', '\ cms query limits all', '| drop 1', '| spec /listdir/ 1 w1 nw /./ n', '| cms', '| pick w1 ¬== /Fm/', '| spec /query auth/ 1 w2 nw', '| cms', ... '| sort', ... Regards, Richard Schuh
