The whole site seems to really be mostly about COBOL, not so much about other legacy languages or aspects related to mainframes.
Why is this, is this on purpose or just my impression?
The whole site seems to really be mostly about COBOL, not so much about other legacy languages or aspects related to mainframes.
Why is this, is this on purpose or just my impression?
Thanks for the feedback @johann_petrak!
You are correct that the initial focus has been COBOL. If you’d see interest in additional languages, we are happy to create dedicated forums. Let me know which one’s should be created.
To be honest, I do not know
I have worked with mainframes a long time ago and the most frequent languages I have used have been PL/I and FORTRAN77 plus a few that probably/maybe do not matter at all any more (e.g. APL and S/370 macro assembler).
I would be curious myself how much code in those languages is still around.
I certainly would be interesting, and if there is interest happy to create additional forums if there’s an audience.
There are definitely hobbyist websites, actively discussing (some of) these topics. If interested, let me know and I can give you some groups (in groups.io) to check out! Actually, I will include a link to many of them. And by the way, APL has been preserved by the the Computer History Museum. It’s all here: https://github.com/FuzzyMainframes/Awesome-Mainframes Enjoy!
Hi, my view is that whilst PL1 and Fortran were prevalent in the 60s and 70s and well into the 80s… they were rarely underpinning large mainframe transaction crunching systems, COBOL was the preferred option for many large companies for number crunching batch systems. I would guess that as fewer systems were developed with the other languages, these were either replaced or fell out of use. The cost to replace the more prevalent COBOL systems has clearly been a much bigger issue in the USA… in the UK, there are far less COBOL systems and it’s rare to see jobs linked to legacy COBOL systems. I’m not sure why there is such a disparity between the UK and USA with regards to legacy COBOL apps. Maybe it’s just down to funding and the fact that the UK invested sooner in replacement technologies.
Interesting!
When I was programming on a mainframe in the 80ies (in Austria), even back then COBOL was already considered outdated and in our case, almost everything was written in PLI which was considered to be much more advanced and modern in comparison.
I started doing Cobol programming in 1972 and did projects for a large number of US companies and a few in other countries. My only involvement with PL1 was a conversion project to Cobol. I was hearing that Cobol was outdated and to be replaced by something more modern almost from the first day I learned it. I guess that is yet to happen.
I use PHP and the LAMP stack environment now and like it a lot–but I still do some Cobol and still have a lot of respect for it. For all its supposed shortcomings, it is damn good at what it was intended to do.
part one;
Blame game… The vendors who were tasked with maintaining and updating these legacy systems needed and easy target … Yup you guessed it … It was COBOL’s fault. In reality it was the servers who couldn’t scaling when their network demands increased. All of the problems pointed to people having trouble signing on from their accounts from unemployment benefits.
part two:
PL/I is an ugly step child of Cobol and Algol (yes I maintained and wrote a quite a few PL/I programs in my time)… No it’s not a very pretty language by comparison to what’s available today through vendor offerings. Rumor has it that there were some IBM products written in PL/I that were pilfered , and now exist as OEM copies somewhere in Asia. Which might account for some of the remaining PL/I popularity. If you have XLC on z/OS i’d heavily advise using it instead. Although it’s only Cxx14 compliant as far as I know.
happy coding
Simple: COBOL still been heavily on financial institutions while others such FORTRAN, PLI and so aren’t.
Regards!