Re: Error handeling (Was: How to stop PIPE STARMON)
On Wed, Jun 11, 2008 at 12:29 PM, Berry van Sleeuwen <[EMAIL PROTECTED]> wrote: > Are you sure this will work in all cases? The context of my suggestion was sipping pipelines in REXX. I do believe the streamstate does what makes sense, but I will check again when I get home. > But more in general, there are more commands that will exit a returncode > based on their function. WAKEUP for instance. Just a small test confirms I should have been more clear about the context. I do hope you would not be tempted to run wakeup from inside a REXX stage (and I don't use it at all now that we have pipes). PS The CMSPIP-L is probably a better place for this kind of threads. Rob
Re: Error handeling (Was: How to stop PIPE STARMON)
In that case, insert signal off error before and signal on error after the streamstate. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Berry van Sleeuwen > Sent: Wednesday, June 11, 2008 3:29 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Error handeling (Was: How to stop PIPE STARMON) > > Hello Rob, > > Are you sure this will work in all cases? > > The SIGNAL ON ERROR will react to any non-zero returncode. > STREAMSTATE ca= n have returncodes 0, 4 and 8, and it looks > to me that all three are acceptable, at least in my case. > Only rc=12, stream not connected, is = > > indeed the returncode I will trigger upon. But the SIGNAL ON > ERROR will = > > exit the stage in all returncodes other than zero. > > But more in general, there are more commands that will exit a > returncode = > > based on their function. WAKEUP for instance. Just a small > test confirms = > > this: > > signal on error > 'wakeup +00:30 (cons' > say rc > error: > exit rc > > The result is that wakeup will return rc=2 when the timer > expires and 6= > > when the console interrupt is received. In both cases valid > returncodes, = > > or perhaps required returncodes, but in both cases the SIGNAL > traps the 'error' and skips the "SAY rc" command. > > In such cases it looks like errorhandeling should be coded > for every individual event instead of a general error handeling trap. > > Regards, Berry. > > On Mon, 9 Jun 2008 21:38:15 +0200, Rob van der Heij > <[EMAIL PROTECTED]> = > > wrote: > > >signal on error > >do forever > > peekto > > .. process.. > > readto > > streamstate output > >end > >error: return rc * ( rc <> 12 ) >
Error handeling (Was: How to stop PIPE STARMON)
Hello Rob, Are you sure this will work in all cases? The SIGNAL ON ERROR will react to any non-zero returncode. STREAMSTATE ca n have returncodes 0, 4 and 8, and it looks to me that all three are acceptable, at least in my case. Only rc=12, stream not connected, is indeed the returncode I will trigger upon. But the SIGNAL ON ERROR will exit the stage in all returncodes other than zero. But more in general, there are more commands that will exit a returncode based on their function. WAKEUP for instance. Just a small test confirms this: signal on error 'wakeup +00:30 (cons' say rc error: exit rc The result is that wakeup will return rc=2 when the timer expires and 6 when the console interrupt is received. In both cases valid returncodes, or perhaps required returncodes, but in both cases the SIGNAL traps the 'error' and skips the "SAY rc" command. In such cases it looks like errorhandeling should be coded for every individual event instead of a general error handeling trap. Regards, Berry. On Mon, 9 Jun 2008 21:38:15 +0200, Rob van der Heij <[EMAIL PROTECTED]> wrote: >signal on error >do forever > peekto > .. process.. > readto > streamstate output >end >error: return rc * ( rc <> 12 )
