I hoped the readers would realize that my code snipped wasn't meant to have
a real text, I wanted to illustrate what I can code.
So, you begged for real examples, here from SFSULIST EXEC:
if fpool='' then do
'QUERY FILEPOOL CURRENT(LIFO'
parse pull . fpool .
if fpool='NONE' then call ErrExit 5,'There is no default filepool',,
'Issue' Myname 'fpool',,
'or SET FILEPOOL fpool and 'myname
end
/* Is filepool available ? */
'PIPE COMMAND CMDCALL QUERY LIMITS *' fpool '|VAR EMSG'
if rc<>0 then call ErrExit rc,emsg
The example also illustrates how to grab messages from commands that
normally don't produce error messages when called under control of ADDRESS
COMMAND (or PIPE's COMMAND stage): you insert CMDCALL before the command
--
Kris Buelens,
IBM Belgium, VM customer support
2010/2/25 Schuh, Richard <rsc...@visa.com>
>
>
>
> Regards,
> Richard Schuh
>
>
>
>
> ------------------------------
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Kris Buelens
> *Sent:* Thursday, February 25, 2010 7:06 AM
>
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: An SFS aid
>
>
>
>
>
> I agree with the "use Signal sometimes", in cases where one will not
> return, it is more clear indeed. But, the example above "if rc<>0 then
> signal Error" isn't very practical: you cannot pass parameters. So I have a
> Call to my errorexit: routine. The name of the called routine makes it
> clear to the reader that one will not return from there.
>
> It could have been "signal errorx" instead of a generic "signal error"
> where errorx knows the message to display. The variable rc is still
> available to it and can be included in the message.
>
>
> if rc<>0 then call errExit rc,'Something was wrong','Please try again'
>
> That message is too generic and not at all helpful. It defeats the purpose
> of the call. As stated above, the rc is still available to the error
> routine, even if signal is used.
>
>
