Ok, but I have written a lot of Rexx stages and have never done anything to explicitly commit. So, how does that work? What'd be the benefit to going back and adding such logic? Is committing something any Rexx stage should *always* do explicitly? If not, how do you know when it is needed? etc.
bc On 9/7/07, Glenn Knickerbocker <[EMAIL PROTECTED]> wrote: > > On Thu, 6 Sep 2007 14:42:21 -0400, Bob Cronin wrote: > >Can anyone give a good reference to material that explains what the heck > >this committing to levels business is all about? > > To start with, just ignore the level numbers. For a REXX stage talking > to any built-in stages, either it has committed (to level 0) or it > hasn't (and is at level -1). > > The idea is for every stage to commit before the pipeline actually does > anything. Once a stage commits, it won't run again until every other > stage in the pipeline set has also committed. This gives every stage > the chance to bail out before any stage has read any input or written > any output. Take this trivial example: > > PIPE < nonexist file a | > exist file a > > If NONEXIST FILE doesn't exist, < exits without committing. Then, > when > commits, it sees the nonzero return code set by < and knows not > to erase EXIST FILE. > > (Slightly headspinning detail: REXX stages start at level -1, so > anything the built-in stages do below commit level -1 is already done > before any REXX stage starts. Built-in stages never commit to levels > higher than 0, so anything the REXX stages want to do above commit level > 0 has to wait until after all the built-in stages have ended.) > > ¬R http://users.bestweb.net/~notr/bluemoon.html > "Nothing says 'Thursday' quite like Ira Fusfeld." >
