Hello Kris,

You are right. I had just changed an existing rexx that was constructed 

this way. Or rather, I had put a READTO into the rexx just to be able to 

be able to process the input before it enters a pipeline in the rexx. And
 
indeed it would be better to PEEKTO/READTO or even more so, to check 
returncodes. I don't mind to delay records here, the stage writes records
 
to disk and doesn't output them to an output stream.

But the original, as well as my new one use 'CALLPIPE *:' rather 
than 'READTO input ; CALLPIPE VAR input,'.

So in this case the input is not checked. The jeremy stage did note that 

inside the rexx stage a callpipe specs was in wait.locate and a lookup wa
s 
in wait.locate but nothing about the returncode of the READTO command. An
d 
I didn't trace the rexx itself in that detail so I didn't notice the rc 1
2 
of READTO. I did now and indeed the return code is 12. Just a test with 

CALLPIPE *: reveals that the CALLPIPE do not end in a returncode so even 

when the input stream has severed the callpipe *: doesn't notice it and 

doesn't set the pipeline returncode. Instead it continues processing.

So now, with the connector in the callpipe I do need to check my input 

stream before the callpipe connects to it.

Regards, Berry.

On Mon, 9 Jun 2008 15:08:05 +0200, Kris Buelens <[EMAIL PROTECTED]> 

wrote:

>'STREAMSTATE INPUT' should not be required here...
>
>My guess is that "process" has set the returncode to 0, so your
>do-loop condition check is not testing the return code of READTO.
>The pseudocode also suggests your stage does "delay the record".  You
>should code it like this:
>'PEEKTO INPUT' /* Get first record, without consuming it */
>Do while rc=0
>  <process>
>  'READTO'   /* consume the handled record */
>  'PEEKTO INPUT' /* get next record or stop */
>end

Reply via email to