On 8/29/2012 5:03 PM, I wrote:
> Failing that, the best option I've come up with is a loop that checks
> whether the first data set is already allocated and SUSPENDs until it's
> free.  That will obviously choke if it's allocated before the pipeline
> starts, or if my stage fails before freeing it.  Any better ideas?

I ran into a more subtle problem with this loop.  I tried reading the
data set that needs to be reused into a BUFFER before freeing it:

  'addpipe <' workfile '| literal | buffer | *.in:'
  'readto'  /* drop the extra line once the file is in BUFFER */
  'callpipe tso free' etc.
  'short'

Problem is, I never got control back from READTO when the second stage
issued SUSPEND.  SUSPEND returns 0 and the second stage gets control
back right away.  I tried it out with no subroutine pipelines involved
and got the same result:  When one stage has issued PEEKTO or READTO,
SUSPEND in the other returns 0.  So why aren't the reading and writing
stages ready to be dispatched?

The only thing I found that returned control to the first stage was for
the second one to issue another PEEKTO.  After both stages had been
waiting to read at once, then SUSPEND in the first would return control
to the second.

  PIPE (end /) trysusp 1/trysusp  2
   stage 1 -> SUSPEND
   stage  2 -> SUSPEND
   stage 1 -- SUSPEND returns 1
   stage 1 -> PEEKTO
   stage  2 -- SUSPEND returns 1
   stage  2 -> SUSPEND
   stage  2 -- SUSPEND returns 0
   stage  2 -> PEEKTO
   stage 1 -- PEEKTO returns 12
   stage 1 -> SUSPEND
   stage  2 -- PEEKTO returns 12
   stage  2 -> SUSPEND
   stage 1 -- SUSPEND returns 1
   stage 1 exits
   stage  2 -- SUSPEND returns 1
   stage  2 exits

In the case at hand, I don't have any other work I might need to do
while the output file is still in the pipeline, and I was able to worked
around this by holding the file in REXX variables instead of the pipeline:

  'callpipe <' workfile '| stem out.'
  'callpipe tso free' etc.
  'callpipe stem out. | *:'

I worry that I might still be setting myself up to fail, though, if it's
ever possible that < and STEM will come off the dispatch list prematurely.

¬R

Reply via email to