Very good method ... I was teaching programming during my career, much
the same as you did,
but I never did it like that. But I also encouraged the students to
discuss their solutions with me
and with other students and required that there be comments and
meaningful variable names etc.
IMO, the COBOL language and the mainframe is still alive and will not
die in the near future for the
following reasons:
- the applications are more secure because of the use of decimal data
(0C7 will often occur, when
uninitialized data is used ... this is often detected during testing. On
other platforms, you may get
unexpected results, but no abends)
- if you get an ABEND, you have well established analyzing and recovery
procedures and readable dumps;
compare that to a "segmentation fault" on a Unix box ... you normally
need to start a debugger to
examine the problem (in the production system?)
- most mainframe shops have established procedures for change management
etc., and software
doesn't go to production untested etc.
- the system software stack is stable ... on the other platforms, it is
possible that a software after only
3 years is "legacy" or "toxic" ... with mainframes, legacy starts after
25 to 30 years :-)
and the software is still readable (well: normally).
Kind regards
Bernd
Am 28.03.2023 um 23:17 schrieb Steve Thompson:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
