I thought the "eofreport" subcommand was created to catch end of file on output? Or is there a reason not to use that? I've used this skeleton written by Steve Hayes as a starting point to create simple filters for quite awhile:
/*--------------------------------------------------------------------*/ /* NULL REXX: Skeleton stage that does not delay the record */ /* Steve Hayes 1997-03-20 */ /*--------------------------------------------------------------------*/ trace o /* in case of stall */ signal on novalue /* No uninitialised varibles */ signal on failure /* Allow RC > 0 for a moment */ 'MAXSTREAM INPUT' /* Check only one stream */ signal on error /* now stop for any error */ if RC <> 0 then 'ISSUEMSG 264 PIPSJH' /* too many streams: crash */ 'EOFREPORT ALL' /* propagate EoF back */ do forever /* until EOF */ 'PEEKTO record' /* read from primary input */ 'OUTPUT' record /* write to primary output */ 'READTO' /* release input */ end /* next record */ failure: error: exit (RC * (RC <> 12 & RC <> 8)) /* RC = 0 if EOF */ On Mon, Jun 9, 2008 at 3:38 PM, Rob van der Heij <[EMAIL PROTECTED]> wrote: > On Mon, Jun 9, 2008 at 3:08 PM, Kris Buelens <[EMAIL PROTECTED]> wrote: >> 'STREAMSTATE INPUT' should not be required here... > > In most cases the suitable approach is to use > > signal on error > do forever > peekto > .. process.. > readto > streamstate output > end > error: return rc * ( rc <> 12 ) > > The 'streamstate output' is something that I recently started to > ensure backward propagation of eof into the stage (when the pipeline > on my output has terminated, this also terminates the rexx stage). > -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
