I didn't want to start a war of words about a poor little Signal, but I cannot resist now. SIGNAL should be used only if you want to branch to a piece of code from which you will never come back. In other words, it should be reserved for *abnormal* changes in the flow of logic. Error handling is fine. Anything else and you are in danger of creating a dreaded spaghetti mess.
As with all generalizations, including this one, yours is bad :-) There are > places where signal is not bad. For example, I have an EXEC that acts as (a) > an EXEC, (b) a Pipelines filter and (c) an XEDIT profile. > Nothing that cannot be coded without SIGNAL. > There is no pretense that the filter or the XEDIT profile will return to > the initial line of code. > Except if you use another Signal to achieve exactly that, which was the case in Ray's program. > Signal to get to the proper section of code is perfectly good in this > situation, in fact I contend that it is preferable to CALL. > That's a matter of taste or, if you want, choice. In your case, if you have three big chunks of logic that don't mix well with each other, then maybe yes. But, I would still use different parameters for each mentioned environment and a mainline with three CALLs. > In some cases, constructing a signal-less program results in more > complicated, more difficult to read and understand code. I would prefer the > more maintainable program over one that was pristine, without signals. > I also prefer more maintenable program, but such a program shall be with as few signals as possible. > This bit that signal (goto, branch, Etc,) should *never* be used is > nonsense, an outgrowth of the misapplication of the "Top-down Structured > Programming" concepts. > I never said "never". I clearly stated the exceptions. I also never mentioned goto nor branch. That is *your* generalisation. BTW, SIGNAL and GOTO are not exactly the same. SIGNAL terminates all constructs from within which it was executed irrespective of wether the target label is within the same construct or outside of it. Some languages allow GOTO to jump to any instruction in a program. In PL/I it is limited to active blocks and GO TO does not terminate a construct if the target label is within the same construct, so you can jump around the same DO loop without terminating it. You cannot do that with SIGNAL. Its nature of bringing you to the top level of nesting before it branches lends itself to usage in abnormal conditions only. In my eyes at least. > People went wild over-modularizing programs. I supported (I was in field > support for Amdahl at the time) one client that had modularized to the > extent that each module consisted of no more than 5 (some were only 2) > actual COBOL statements. The rest of each module was comprised of set-up and > termination code. Each was compiled separately. Most were only called from > a single program; many only called from one place in that program. He > wondered why the system was using so much cpu time and running so slowly, > saying, "It wasn't that way before." When I asked, "Before what?", we were > able to quickly determine source of the problem. > That's a horror story, and you can't score points with horror stories. :-) Extremes, exaggerations and overzealousness don't count in rational comparisons. Making too many small modules is, of course, counterproductive. In general, I will always vote for modular programming - one entry point with the defined set of parameters, clearly defined function, one exit point and when you complete the module, you know what that piece of code does and you can put it away after testing it. When you test a program full of GOTOs, you constantly test the same piece of code over and over only under constantly changing conditions. > On the other hand, I have seen the worst of the worst. When I made the > switch from application to systems programming, one lady was sent to me to > see if I could help her with her dump. This was in 1969, the system was > OS/360, the language, COBOL . I started following the code in the dump and > found that I was flicking through the pages of her program in a wildly > random way. I finally got her to admit that when she sent a program to > keypunch, she made sure that the divisions were in their proper place and > that the statements of all, with the exception of the Procedure Division, > were in the proper order. She didn't bother sorting the PD. When the program > came back from keypunch she started her process of compiling and testing, > inserting GOTOs wherever necessary to make the instructions execute in the > proper order, perhaps a logical (or illogical) sort. The program was large; > the number of statements on a coding sheet, small. The number of GOTO > statements was substantial. > Another horror story which I obviously cannot take advantage of. :-) I'll just say that whenever I see a program full of GOTOs, I roll my eyes in despair. Last time I used GOTOs with joy was with HP-41 programmable calculator more than 30 years ago. There was no better option. Ivica Brodaric
