On Feb 4, 2011, at 08:40, Thomas Berg wrote:
>
> I don't quite understand Your problems with SIGNAL. AFAICS, You use SIGNAL
> when the situation is such that You can't handle it within Your REXX routine
> logic/context. That's is, You must abort all processing and (normally) give
> a comprehensive error message, maybe also log it.
>
For that, CALL and EXIT suffice; no need for SIGNAL.
> You describe a situation where a large input file was handled. If that were
> the reason for the crash it means that too much data was stored in memory
It does not mean that.
> (instead of reading smaller amounts at a time from the file or storing
> temporary data in a disk dataset).
>
I was not the author. It became my problem only when I was called on
to analyze it. Something such as:
/* Rexx */ signal on novalue; /*
Doc: "signal" considered harmful.
*/
I = 0
A: I = I + 1
call P
say I 'was processed by P'
signal A
P:
if right( I, 1 ) == 0 then do
say "Ignoring" I
signal A; end
/* whatever */
return
Much surrounding spaghetti redacted. When I succeeded, after
several tries, in explaining the problem to the author, I
believe he replaced the CALL and the RETURN with two more
SIGNALs.
I never have a problem with SIGNAL because I have _never_
(except in demonstrations such as above) coded a SIGNAL to
a label. I always code SIGNAL ON NOVALUE.
There is one larger EXEC of which I was not the author, but
have become the maintainer, which is permeated with SIGNAL
spaghetti. It reads commands from the terminal with a
hierarchy of recognized subcommands. But many of the subcommand
processors recognize top-level commands and SIGNAL directly
to their processors. Necessarily, all the loops are implemented
by SIGNAL, not DO, and all the subcommand processors are
invoked by SIGNAL, not CALL. I hate it. But, following the
spaghetti metaphor, once it's cooked it can't be untangled;
it merely breaks. Someday I'll try setting a switch variable
and RETURN to a SELECT within a DO. Or adding a unified
lexical analyzer.
-- gil
