In an effort to keep people from writing difficult to impossible
to maintain code, while I was teaching COBOL, I warned the
students that I would be picking a programming lesson, where once
it was completed, everyone would have to swap card decks and then
have to add the next lesson's function to it. They would be
graded on getting the lesson done, graded on how well they could
update someone else's code and on how problematic their code was
for another person to update it. And then there would be one more
of these that I would announce with no warning to do before the
final program was due.
So programming task #3 was done and I announced this was the time
for the swap.
After that lesson, and me having graded it, code started to have
meaningful comments and better to understand variable names and
logic. I never pulled the second one on them because I felt the
mission and lesson had been accomplished.
I think more instructors should do things like this.
Steve Thompson
On 3/28/2023 5:01 PM, Bernd Oppolzer wrote:
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
