I started out in the early 80's as a COBOL programmer, learned COBOL at college and JSP (Jackson Structured Programming) which entailed never using GOTO and how

I started out in the early 80's as a COBOL programmer, learned COBOL at college and JSP (Jackson Structured Programming) which entailed never using GOTO and how to code as such, even how to handle exceptions. But no, real world my first program was ripped to bits, rewrote and I was shown the error of my ways and why I should use GOTO as it was how everything else was written and others will need to maintain and modify the program throughout it's life. Hence was the company standard. Even had a system engineer point out how much more efficient GOTO was for error handling and efficiency ruled the waves. So the spaghetti code today may seem silly, but there will be so many historical reasons for the way it is. Alas companies are not keen to refactor old code a bit at a time for something more readable. They all live the dream that one day they will replace the whole system overnight and the angels will sing their praise. But that rarely goes to plan due to legacy factors and how intertwined so many aspects of the various systems are. This and it works, the hardware is fault tolerant. Then the horror stories of failures of others doing as such spread further than any success story. So you end up at best in many cases seeing some aspects farmed out to a data warehouse running on some x86 server to plicate the increasing demands for marketing and sales statistics and provide them the tools to play away without impacting and stealing the pool of resources they have to keep the existing system just ticking along. But the likes of CIC's and MQ interfacing make peeling of some layers much easier and was one of the sain approaches when I last was involved in such matters over a decade ago. Be interested how people migrate such systems today as encountered many a software house who will promise all the tick box's management want to see and fail so very badly.