If I wanted to store it in the same stem, it would be necessary to have a "buffer" instead of either "copy" or "drop 0". I have not tried using elastic when doing that, but that is irrelevant. I was writing to a file, not storing in a stem.
Now for the real solution. I had saved the file and run the exec from the XEDIT command line. I had three or four files in the XEDIT ring. I made changes, saved and executed several times without exiting XEDIT. After exiting XEDIT the do nothing stage is no longer needed. I can even run from XEDIT. That smacks more of memory corruption than anything else. Alas, it does not seem to be reproducible. Regards, Richard Schuh > -----Original Message----- > From: CMSTSO Pipelines Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Friday, January 18, 2008 3:36 PM > To: [email protected] > Subject: Re: Oddity > > On Jan 19, 2008 12:27 AM, Schuh, Richard <[EMAIL PROTECTED]> wrote: > > > Yeah, but it shouldn't be necessary. The use of "drop 0" is > probably > > faster than "elastic", but the application I am building will never > > have enough records to make performance an issue. > > Right, the COPY does not do anything useful there. If it > really makes a difference, then I think it's a bug. And since > you have old plumbing, it might have been fixed already in > plastic pipes. > If you were storing the unmatched detail in the same stem as > your input, the it might be... But this probably is something > else happening. > > Rob >
