Since COBOL 1985 (implemented with an early release of VS COBOL II) you can uses nested programs, which (can) have their own "local variables".
That being said, it's quite a paradigm shift for some COBOL programmers, and I've had pushback from them each time I've used it. It is also just as verbose as any other COBOL program, which causes source code bloat if used extensively. For a small procedure (nested program) there is sometimes more COBOL boilerplate (divisions and sections) outside of the procedure division than there is code inside the procedure division. I'm not discouraging their use, nor am I necessarily encouraging it. ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Bernd Oppolzer <[email protected]> Sent: Tuesday, March 28, 2023 3:01 PM To: [email protected] <[email protected]> Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by value] With the clever use of GOTOs and the use of different variables with strange names for the same purpose, you can even turn a less than 1000 lines COBOL program completely unreadable. I see such programs almost every day. The biggest obstacle for keeping large COBOL programs maintainable is the lack of procedures and local variables, IMO. Because all variables are global, it is almost impossible to structure your program into many small independent and separate blocks, which IMO is crucial when it comes to fighting complexity. You need much discipline and talent, inspired by other programming languages (in my case PL/1 - Pascal - C - Assembler, to name a few), if you want to produce good quality software in a shop who is COBOL only :-( I'm doing this for more than 3 years now ... new COBOL software every day. COBOL is not dead and will not be for the next 10 to 20 years, at least. Kind regards Bernd Am 28.03.2023 um 17:05 schrieb David Spiegel: > Hi Bill, > You said: "...It seems to help with maintenance and updating of large, > complex commercial programs..." > Back in the mid-'80s, I used to support a 3-letter software vendor's > Payroll package. > The source was unreadable because of the amount and size of copybooks. > When compiled, the listing was so big that it was near impossible to > follow. > Needless to say, the variable and paragraph names didn't help too much. > Have you ever tried reading a DMS for CICS (again, 40 years ago) > generated COBOL listing? > My point is that anything can be unreadable, including wordy COBOL. > I used to code FORTRAN, ASSEMBLER and APL for a living (early '80s). > These 3 can be readable if there are departmental standards in place. > > Caveat: I still program Rexx and given the chance would (and have) > program(med) PL/I -- my favourite compiled language. > (Edsger W. Dijkstra be damned. (If he had to work in a commercial (aka > "real") environment (instead of his ivory tower), his opinion might've > been tempered a bit.) ) > > Regards, > David > ---------------------------------------------------------------------- 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
