That's just side-stepping the question(s) Ed :-) I don't know of anywhere where ALTER is allowed (except I know of one guy who "uses it all the time" and likens it to the way he does his shopping in the supermarket) or has been for the last 37 years.
But that was not the point of mentioning ALTER in the discussion. The point is, ALTER = bad name, GO TO ... DEPENDING ON ... = bad name, GO TO = bad name "except where I use it to make the code easier". All of those "became bad", there is no intrinsic problem in them (unless you can win an argument on that) and were in fact even recommended in early documentation. What has made them "bad" is usage, usage outside "best practice". Now, hear comes another GO TO, "disguised" as a "structured concept". So, that's going to g... proceed well, isn't it? No, not really, exactly the same will happen, for sure. OK, I'm not a subscriber to "history repeats itself", but the way people continue to (ab)use GO TO and try to create semi-recursive PERFORMs leads me to that conclusion. On Friday, 15 July 2016 06:42:33 UTC+2, Edward Gould wrote: > Errr try fixing a program that uses alter at 0300. Nothing is clear through > gritty eyes at that time of the AM. > A company I worked at a while ago. I put in the standards manual never use > ALTER and every team leader wanted it emblazened across every programmer > forehead. > > Ed > > > On Jul 14, 2016, at 1:28 AM, Bill Woodger <[email protected]> wrote: > > > > Why has ALTER always been bad? Because of the potential scope of things > > that you can do with it, or because COBOL programmers will ignore or be > > unaware of any "best practice" for using it, or something else? If either > > of the first two, then away goes "EXIT PARAGRAPH/SECTION" into the > > bad-boys-bucket. > > > > If the last, please elucidate, but remembering the context of the time. > > Bear in mind also that it was likely not invented out of thin air for > > COBOL, so likely "best practice" in programming at the time of COBOL's > > development. > > > > I'm not suggesting the use of ALTER (that would be regarded like suggesting > > that faeces are added to your breakfast cereal), or even GO TO ... > > DEPENDING ON ..., or even GO TO, or NEXT SENTENCE, or the new EXIT formats. > > > > I am suggesting the historic record and current observable practice seem to > > indicate that the new EXIT formats will be (ab)used and new forms of minor > > chaos will ensue. > > > > At that point, I'm not going to sit back and tell you "I told you so". I'm > > telling you now :-) > > > > We can attempt to ameliorate with "best practice for the use of new forms > > of EXIT (if you really feel you must use them)". > > > > To me, "structured programming" is not limited by the availability of > > language constructs for "structure". For too many, present company excluded > > until known otherwise, simple using structured constructs does not make a > > program "structured". > > > > "Here's EXIT PERFORM, that looks like a construct in another language that > > is regarded as an aid to structured programming, so I'll use it, then my > > program will be structured". Similar to "But my program works, it uses > > INITIALIZE [when of course it doesn't, and the INITALIZEs are all of fields > > whose contents are replaced by the next line of code]", or "I got a clean > > compile but somehow my program doesn't work". > > > > Of course, anyone can say anything bad they like about ALTER, and get away > > with it, as it is hated. Same with COBOL. As well as "external myth" > > there's self-generated internal myth (like S0C1 for reading a file which is > > not open, and many, many others). > > > > On Thursday, 14 July 2016 06:35:39 UTC+2, Edward Gould wrote: > >>> —————————————SNIP------------------------------------ > >>> ALTER is bad because its not obvious when you look at a piece of code > >>> where it might actually branch to. > >>> > >> > >> > >> Alter has *ALWAYS* been bad. > >> > >> Ed > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
