If you think MVS , MVS/XA , Jes2 or Jes3 , VTAM , IMS or CICS consists of "spaghetti code" I've got a bridge to sell you ... that they are written in languages that many "programmers" would have difficulty writing in today is true ,, of course there aren't many real programmers left, most "programmers" allow programs written by real programmers to take their rough outline of what their program should do and create their work for them ... that is how you get the spaghetti created by MS and others.
That IBM "spaghetti" code was so tight that ALMOST 30 YEARS AGO I could run 1.4 million non-trivial IMS (V1.1) transactions with an average 0.3 second response time on a 3031-AP with 1 megabyte of real memory servicing 2-5,000 users simultaneously. My CSA was 96.5% after an IPL and rose to about 98.5% after 3 days ,, had to re-IPL mid week. You can't get SOLITAIRE to run on 1mb of memory thanks to MS's "expert" coding.
That is why people pay the money ,, it runs , it's tight and it keeps you in business.
If you think MVS , MVS/XA , Jes2 or Jes3 , VTAM , IMS or CICS consists of "spaghetti code" I've got a bridge to sell you ... that they are written in languages that many "programmers" would have difficulty writing in today is true ,, of course there aren't many real programmers left, most "programmers" allow programs written by real programmers to take their rough outline of what their program should do and create their work for them ... that is how you get the spaghetti created by MS and others.
Since the days of OS/360 through z/OS of today, system code One would be hard pressed to call it spaghetti. Since Linux and Java run on zSeries Mainframes Amen
has always been "called function" and macros in Assembler.
it is not cost effective to migrate to PC platforms.
I'm not talking about the code contracted out to and written by IBM... I'm talking about the code written in house by customers who have built in-house of cards applications that currently run on their mainframes that only work today due to being fixed and refixed over many years ... and do mission critical work for the company. I've seen the code and many times untangled it... but there's lots out there.
The problem is re-inventing what already has been done. Some of it very elegantly, as you say, written in tight, concise code... but a lot of it was done very sloppily, sometimes calling programs as sub-routines that was written in other languages. I'm well aware that when memory was tight, you had to write really good code... today, not so much. Lot's of memory and high speed processors lets a lot of sloppy coding be written.
The first largish program I ever wrote was a text editor in machine language on the Apple ][. I entered all of the code via the mini assembler which allowed line-by-line entry of assembly language statements. As I fixed bugs, if the fixed region of code exceeded the size of the buggy code, I had to substitute a jmp to somewhere unused, insert the new code and jmp back. That's spaghetti code.
One of my classmates was writing an assembler at the same time and V2 of that editor was all in assembly and a lot cleaner.
That IBM "spaghetti" code was so tight that ALMOST 30 YEARS AGO I could run 1.4 million non-trivial IMS (V1.1) ...
Oh, I believe you. One of my friends in college in exactly the same time frame (1981ish) once told me he had a dream about me where I was proclaiming "True Programming is Dead!". And it soon became true. Whether it's the fault of OO (of which I am not a big fan) or just sloppiness in general, technique and skill in programming have declined in general over the years.
Flow of control in strictly procedural languages (coined FBAPP - Fortran, BASIC, ALGOL, Pascal, PL/I by my college advisor Jim Kajiya, now with Microsoft) is fairly straightforward. OO languages starting with Smalltalk and continuing with C++, Ada, etc., flow of control becomes a lot more complex. Flow of control through functional languages like LISP, Icon, etc. can be complex, but it's somewhat simplified in the more limited visibility of global symbols.
Personally, I hate global variables[1] a lot more than I hate gotos or OO virtual functions.
My own example of what Neidermeyer is trying to convey is the Woz Sweet 16 interpreter that was included in the Apple ][ ROM. It was barely over a page of ram (about 280 bytes) and emulated a fully functional 16 bit processor on the 8 bit 6502. Absolutely the finest work of art I've ever seen.
The key thing in this article is "who do you call when things break?" With Microsoft, it's either fix it yourself, or wipe the machine and reinstall from scratch. With enterprise solutions, you have people (like me) standing by 24x7x52 to deal with your issue in real time. That kind of support absolutely costs money.
[1] `errno' is the worst idea introduced with Unix. Fortunately, workarounds have been done over the years so we're not crippled with it.