Some suggestions: * GO TO's from in the middle of one SECTION into the middle of another. And then GO TO back again depending on a "switch"... * Programs with nested PERFORMS (*only* PERFORMS!) in maybe 7 levels ending in a CALL of another module. * Field name (variable) in (e g) MOVE statement qualified resulting in more than 100 characters, then add the matching length for the corresponding field. (Take this times 1000 fields...) * Processing the same data sometimes in a character defined field, sometimes in numeric defined fields (several different numeric formats for the same data) without any reasonable explanation. * Need to check four or five different result fields (depending on the situation etc.) for eventual error from the CALL of another module.
And other I have forgotten... Regards Thomas Berg ________________________________________________________________ Thomas Berg Specialist z/OS/IT Delivery SWEDBANK AB (Publ) > -----Ursprungligt meddelande----- > Från: IBM Mainframe Discussion List [mailto:[email protected]] > För Scott Ford > Skickat: den 16 februari 2013 21:26 > Till: [email protected] > Ämne: Re: SV: Article for the boss: COBOL will outlive us all > > Thomas, > > I don't follow, writing in several languages , what awkward to do in > cobol, supervisory stuff yes for sure. > > Scott ford > www.identityforge.com > > Tell me and I'll forget; show me and I may remember; involve me and > I'll understand. - Chinese Proverb > > > On Feb 16, 2013, at 2:53 PM, Thomas Berg <[email protected]> > wrote: > > >> -----Ursprungligt meddelande----- > >> Från: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] > >> För John Gilmore > >> Skickat: den 16 februari 2013 20:25 > >> Till: [email protected] > >> Ämne: Re: Article for the boss: COBOL will outlive us all > >> > >> Tony H wrote > >> > >> | Now back to our regular COBOL, uh, programming. > >> > >> thus alluding to how many of us view of the language. > >> > >> Over a now long career I never took COBOL seriously. I was aware of > >> it, and I even learned to write it by helping COBOL programmers with > >> their problems. It is a verbose but finally very simple language. > >> That said, I could not, and did not, think much of a language > without > >> real storage management, strings, pointers, booleans, etc., etc. It > >> was move-oriented, compile-time bound, and synchronous, and I find > >> these characteristics despicable. > > > > COBOL is certainly not a programmers language. It's very restricted > by its syntax and functionality and is often very clumsy to use. > > But that is also a feature: it's hard to obfuscate - which can be > seen as an asset from the point of maintenance and security. > > (Which do not mean that you can't make unintelligible programs - I > have seen many - but not at the lowest level.) > > It's also helpful when you need to understand the underlying data > structure the program is based on. > > > > > > > > Regards > > Thomas Berg > > ________________________________________________________________ > > Thomas Berg Specialist z/OS/IT Delivery SWEDBANK AB (Publ) > > > > --------------------------------------------------------------------- > - > > 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
