> -----Ursprungligt meddelande----- > Från: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] För Paul Gilmartin > Skickat: den 4 februari 2011 17:54 > Till: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Ämne: Re: SV: Best (or any) practices to rewrite "spaghetti" > > 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.
I had some cases where CALL didn't work as expected but SIGNAL did. Maybe the problem was when the "exit" was a RETURN (external function). > > > 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 > OMG, I didn't foresee such a usage of SIGNAL... 8-o That is calling (or maybe rather signaling) for problems. > 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 Regards, Thomas Berg _________________________________________ Thomas Berg Specialist A M SWEDBANK
