EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: schmitt trigger on April 08, 2020, 08:35:46 pm
-
There is an exciting *new* opportunity for you: COBOL!
I kid you not:
https://www.cnn.com/2020/04/08/business/coronavirus-cobol-programmers-new-jersey-trnd/index.html (https://www.cnn.com/2020/04/08/business/coronavirus-cobol-programmers-new-jersey-trnd/index.html)
Willing to work long hours on tight budgets and antediluvian computers.
-
I am!
And I even got paid to write a COBOL system for Whangarei City Council during my university holidays in 1982/83. The task was to automate the generation of a list of payments to be made that month for all the loans / debentures the Council had raised at various points to pay for things such as water works improvements, mostly from private individuals, but also from insurance companies. Many or most were on a 30 year term so at that time some loans from the early 1950s were still alive, and some new ones were running up until 2010 or so.
I'm happy to report that I made sure the code was Y2K-proof :-)
I've sometimes wondered whether that stuff is still in use.
-
What I find funny is that COBOL was created to be used by common people with no experience in programming and now someone asks for programmers to write software in it. It seems it missed the goals. ;)
-
Yes and object oriented programming was going to make code clear and always easily reusable. <snicker>
-
Banks use COBOL for their backend stuff. They are slowly moving to other stuff, mostly Java. I'm guessing they will be done when Java is also obsolete.
At the same time COBOL programmers get paid very well, since it is hard to find them and nobody wants to learn dead tech.
-
What I find funny is that COBOL was created to be used by common people with no experience in programming and now someone asks for programmers to write software in it. It seems it missed the goals. ;)
It achieved its goal for a time it was invented. Better things came along later, as it always happens.
I would not recognize COBOL code if I see it, but I bet it is not that hard to figure out. It is just a pointless waste of time, unless it comes with a huge pay.
There is no absolute time-proof technologies. It must be on the code owner to maintain and update it once in a while.
-
COBOL is still a good language for a young person to learn. There is demand, but most youngsters want to be working with the latest and greatest fashion. That means the jobs tend to be really well paid. If the demand for COBOL ever goes away, a capable experienced COBOL programmer won't take long to pick up whatever is the language de jour.
-
COBOL is a very verbose language, very easy to understand. In my opinion there is a need for COBOL programmers for mainframe, including CICS transaction processing system and DB2 or other vintage database systems. Just COBOL is very easy and can be learned in very short time.
-
COBOL was developed in the 1950s, the fact that it is still in use and there is still demand for COBOL programmers says something I think. I've never played with it myself but obviously it gets the job done.
Does anyone think Javascript or Swift will be in common use 70 years from now?
-
COBOL was developed in the 1950s, the fact that it is still in use and there is still demand for COBOL programmers says something I think. I've never played with it myself but obviously it gets the job done.
The reason it is still used is because there is a lot of systems that were not updated since tha time, not because it is such a great language that new things are being developed in it. Since most of it is not directly exposed to network or any untrusted data, it’s not a problem — those systems may as well run fine for the next 50 years, giving jobs to generations of peole knowing obscure languages.
-
COBOL was developed in the 1950s
Not "the 1950s". The committee to design it was started in April 1959, the initial specification was published in January 1960, and the first two implementations were able to run a standard example program in August and December 1960. Widespread adoption was some time later.
Let's be generous and use 1960 as the date. That's 60 years ago.
the fact that it is still in use and there is still demand for COBOL programmers says something I think. I've never played with it myself but obviously it gets the job done.
COBOL was designed to represent the problem domain, not to reflect or be influenced by current computer technology at the time, even if that meant it was inefficient. This is a good thing for longevity.
Does anyone think Javascript or Swift will be in common use 70 years from now?
JavaScript was designed and deployed to millions of users within a few weeks in 1995. That's already 25 years ago, so it's only got 35 years to go to match COBOL today.
Yes, I hate the idea, but I'm sure JavaScript will still be supported in every web browser in 35 years from now, and used by huge numbers of web pages.
C is from 1972, which makes it 48 years old. I'm absolutely confident it will be still in wide use in another 12 years.
Swift is a tougher proposition. It has a lot of competition as a high performance applications programming language (replacement for C/C++) from Go, Rust, D, C#, Java, Kotlin. Swift is a bit more advanced and powerful than most of those, having taken a lot of influence from the ML, CAML etc school. Apple has invested a huge amount in it since 2010 (public release in 2014), the compiler and libraries are extremely mature and optimised, it is open-sourced and available on Linux and IBM's mainframe z/OS (as a competitor to COBOL). I don't think Apple will switch to anything else any time soon, which makes it a major language for as long as the world's largest and most profitable company stays in business and important. Will that be 50 or 55 more years? I don't know. That's a long time. I'd be very surprised if it's less than 20 or 30 years though. Learning Swift is one goal of my current funemployment on the list I made a month ago :-) (along with FPGAs, Webasm, and Go)
-
I also learned COBOL while in college in the mid-1970s, although never used it professionally.
COBOL is a little the old Volkswagen Beetle. A severely outdated platform, but got its job done, once you were aware of its limitations. And simple to understand.
-
"Literally, we have systems that are 40-plus-years-old," New Jersey Gov. Murphy said over the weekend.
Well that makes me feel a shit load better about the 15 years of technical debt I'm hacking through :-DD
Seriously though if you're having problems finding people to look after your stuff because it's literally that old that no one is interested it's time you hired some consultants in to reduce that business risk by replacing it. If you got to the point that no one understands what is left, a problem I see regularly, then you fucked up. Thus this is a fuck up.
I worked with a company that had half their internal ERP ops running off a single AS400 node back in about 2003. That was at the time about 10 years old and they had no staff who even knew how it worked and someone had not paid IBM any money for at least 5 years. I migrated it and their equally obsolete netware setup to windows XP / 2003 and SQL Server / ASP.Net.
-
As I said in another thread, COBOL is not dead: https://en.wikipedia.org/wiki/COBOL
And COBOL-2014 has a lot more than what it was in the 60s.
It has also proven for decades that it worked for this kind of applications. Why switch to languages that have a long track record of software security issues and nasty bugs?
-
I am!
And I even got paid to write a COBOL system for Whangarei City Council during my university holidays in 1982/83.
.. snip ,,
I'm happy to report that I made sure the code was Y2K-proof :-)
I've sometimes wondered whether that stuff is still in use.
I am no longer surprised at the common life experience I have with some forum members. My first paid programming job was fleet vehicle maintenance records and statistics system built from the ground up in COBOL during summer holidays 1979. The summer job was instigated by a mechanical engineer who wanted to light a fire under the computer services department which was stalling him. So I landed into this political mess, I was all on my own and had to fight the people who controlled access to the Univac 1108 mainframe and who wanted to see me fail, but I didn't.
My code was for sure not Y2K proof, two digit year codes everywhere for the win!. Also I never wonder about it as the company went under some 20 years later :-DD
-
Why switch to languages that have a long track record of software security issues and nasty bugs?
Productivity, integration, cost, staff availability, better tooling, better user interface.
You can write bugs in COBOL too.
-
I'm happy to report that I made sure the code was Y2K-proof :-)
Hehe, good job.
But anyone designing financial software in the 80's not Y2K-proof (so that would be less than 20 years ahead - which is pretty average for a real-estate loans for instance) would really be ultra short-sighted. Glad you were not. ;D
-
Why switch to languages that have a long track record of software security issues and nasty bugs?
Productivity, integration, cost, staff availability, better tooling, better user interface.
You can write bugs in COBOL too.
Don't underestimate the cost of replacing the whole system though. I'm sure any of us who have been involved in tech long enough have seen some sort of boondoggle where and old but still functional system was replaced by something new for the sake of being new. The whole thing vastly over budget, rife with problems, etc. If I were starting from scratch I'd never advocate using an obscure language but it can be hugely expensive to replace an entire legacy setup and sometimes the money just isn't there.
Besides, as passionate as some people get about programming languages, it all ultimately boils down to machine code anyway. What can be accomplished in one language can usually be accomplished in another though maybe not nearly as easily.
-
I think the issue apart from cost is usually the idea of replacing the system with one identical built in new technology rather than building a new system for the business requirements of the day. If the money isn't there then the business is a failure. Typical of companies that see IT as an operational cost rather than an advantage.
I knew a small business here in the UK that learned that the hard way when they had an EOL legacy system fail on them. They didn't budget anything for their IT provision to replace it preemptively, ended up with a £2m bill because no one would poke the steaming pile with a stick and had to fold instead. If you operate your business under any reasonable quality framework rather than sweeping business risks under a rug then you tend to do better. The money being there is no excuse. That's how you screw your customers and employees.
As for all of this, the most expensive bit of any system is the humans. So I'd rather give them tools which give me the best time to market with cost and reliability compromises as a whole. It's 2020 so you almost always have to integrate with numerous 3rd parties.
-
Well, yes that's not wrong, but it also ignores reality, sometimes the money just isn't there, so what do you do? Close down a business that is still paying the bills because you decide it's a failure that you don't have the money to upgrade? A failure can be catastrophic, you just have to hope that doesn't happen.
It's not much difference than someone who patches up their house or gets by with an old obsolete service panel (consumer unit). It might make sense in the long run to upgrade to a modern one rather than trying to add another circuit to what you've got but when the upfront cost is an order of magnitude greater many people simply don't have the money.
-
Usually you hide it from your customers, go bankrupt and take them with you in corporate America I understand :-DD
-
You really think that banks , which run big-iron' are going to switch to script-kiddie languages like python ? no chance ...
Time is money. It has to be rock-solid, deterministic and transactions need to be guaranteed and atomic. Cobol was designed for all that. There is no wiggle-room.
-
I was a principal solution architect at a clearing bank here for ref. You couldn’t be more wrong.
90% of it was java backed on DB2. The rest was python and shell. There was no COBOL. Even front office was java SE.
As for atomicity you have to consider a much much larger scale transaction architecture than the scope of a single chunk of cobol. All banking systems are “eventually consistent” architectures so there are transaction and reservation arbitration processes Instead of atomicity.
-
I agree with bd139, COBOL as language is not what makes Banks, Airlines and other large enterprises keep legacy systems. It is the surrounding environment (Very robust and reliable hardware - mainframe, proven OS - MVS, proven volume transaction system - CICS, robust database and storage - DB2, VSAM). You can program in COBOL, Assembly or any other language that was available in the same robust environment.
-
Yep. It’s even moving away from some of the traditional “reliable hardware“ as it’s too expensive and difficult to scale out. Two of the major banks here have significant Kubernetes clusters replacing zSeries and moving to redundancy at a software level.
-
I am!
And I even got paid to write a COBOL system for Whangarei City Council during my university holidays in 1982/83.
.. snip ,,
I'm happy to report that I made sure the code was Y2K-proof :-)
I've sometimes wondered whether that stuff is still in use.
I am no longer surprised at the common life experience I have with some forum members. My first paid programming job was fleet vehicle maintenance records and statistics system built from the ground up in COBOL during summer holidays 1979. The summer job was instigated by a mechanical engineer who wanted to light a fire under the computer services department which was stalling him. So I landed into this political mess, I was all on my own and had to fight the people who controlled access to the Univac 1108 mainframe and who wanted to see me fail, but I didn't.
Yeah, something similar in this case too. The bureau who owned the computer (a PR1ME by that stage, not the B1800 I'd used as a highschool student in 1980) were dragging their heels over implementing this system. I'm not sure if they were actively opposed to the council getting a student to write this system, but I think they weren't thrilled.
My code was for sure not Y2K proof, two digit year codes everywhere for the win!. Also I never wonder about it as the company went under some 20 years later :-DD
Sadly, that bureau insisted I use two digit years to save storage space. I had quite a fight with them about it. In the end I used two digit years but I had a special database table with one record which contained several parameters including a "century rollover year". I initially set this field to "50" meaning that 50..99 meant 1900+year while 00..49 meant 2000+year. I provided a UI for adjusting this parameter, after checking that any loans with dates falling between the old and new base values had already been aged (deleted) from the system.
If they're still using that code and still raising loans with maximum 30 year term then 2020 will be first time they've *had* to adjust the parameter.
-
Why switch to languages that have a long track record of software security issues and nasty bugs?
Productivity, integration, cost, staff availability, better tooling, better user interface.
The two first are nice buzzwords, but the effective benefits using more "modern" languages don't always hold in real projects.
What do you mean by "better user interface"?
Regarding staff - and cost, which is tightly related for software development - things are not necessarily as obvious as it may seem. Of course you can find way more developers for Java, Python or the like. Numbers don't make quality or success though. A couple of very experienced developers (which you are more likely to find among COBOL developers) can be a lot more productive than 10 Java kiddies. So this shortage may actually be a plus rather than a minus.
There certainly are very few people able to develop in COBOL these days, but as long as there are enough to get the job done, I don't see the problem. Sure they are highly paid given the shortage (which motivates them even more to do quality work), but does that make projects more expensive in the end? I'm not convinced, and experience in other fields has often taught me otherwise. And given the current situation (you may wish it were different, it won't change reality), I think anyone serious about working as a software developer in the banking/financial domain should still learn COBOL. It's fine not to be interested in these domains whatsoever though.
Then of course comes the main point: maintaining and evolving legacy systems. Rewriting software from scratch has a long track record of spectacularly failed projects, in all kinds of domains.
Lastly, as I said, COBOL seems to have evolved quite a bit, and I believe it even has object-oriented features these days.
You can write bugs in COBOL too.
Of course. My point here was, using domain-specific languages, there's a whole range of bugs/security issues that you can avoid compared to using very general-purpose ones.
FORTRAN was also another interesting example.
Of course you can write numerical analysis software in C, C++, Java, Pascal, Ada, whatever. (And I have - I'm not specifically advocating FORTRAN, I have never used it outside of uni.) But there's a good chance it'll take the average specialist more time, introduce more bugs, and will make them have to look for third-party libraries that may be costly or utterly buggy, or take months writing their own. So that's really about domain-specific languages and tools.
-
Why switch to languages that have a long track record of software security issues and nasty bugs?
Computer languages split into ones with a long track record of software security issues and nasty bugs, and ones with a short track record of existing.
-
Why switch to languages that have a long track record of software security issues and nasty bugs?
Productivity, integration, cost, staff availability, better tooling, better user interface.
The two first are nice buzzwords, but the effective benefits using more "modern" languages don't always hold in real projects.
They're really not buzzwords.
Productivity is the ratio of time spent to problems solved. You want to have a library of tools which is adaptable to all problem domains without having to reinvent any wheels if possible. Integration is the ability to interact with disparate other systems. No system is an island now.
I'd like you to show me how much work is involved in a realistic case of financial portfolio valuation without modern languages. The task is basically:
1. Map a list of product providers to portfolio items (around 60,000,000 daily) and retrieve them from a mix of SQL boxes and document stores.
2. Fracture this out into distinct queues per provider.
3. Fire this at about 40 different distinct integrations (ranging from shitty bits of SFTP, SOAP, XML, HTTP, JSON, custom protocols all using different auth methods ranging from OAuth to broken ass custom X509 certificate CAs) using batching.
4. Reliably poll, or be sent responses.
5. Match the responses to portfolios (this actually is a very complex matching engine which is nearly 2 MLOC on its own to give you an idea of the scale).
6. Update database and document stores
7. Dynamically generate 60,000,000 portfolio reports in multiple document formats
8. Print them and stuff them in envelopes and order deliveries across 25 countries...
I'd love to see how someone even approaches that with anything that is older than a few years. We're just onboarding protobufs channels. Do you have an implementation of protobufs for COBOL?
What do you mean by "better user interface"?
Someone who knows windows or a web interface can sit down and use it without having to use some shitty terminal emulator or turd written in some vile GUI toolkit dragged along (mostly whining about HP / ME10 / CoCreate shite there but it exists elsewhere).
Regarding staff - and cost, which is tightly related for software development - things are not necessarily as obvious as it may seem. Of course you can find way more developers for Java, Python or the like. Numbers don't make quality or success though. A couple of very experienced developers (which you are more likely to find among COBOL developers) can be a lot more productive than 10 Java kiddies. So this shortage may actually be a plus rather than a minus.
LOL that's just complete bollocks. Sorry
In COBOL you pay someone to write the libraries then they write the application.
In Java you pay someone to write the application using the libraries off the shelf. You also get a test suite for your money. You get documentation. You get continuous integration and delivery. And importantly you get to choose the target architecture not be constrained by it.
There certainly are very few people able to develop in COBOL these days, but as long as there are enough to get the job done, I don't see the problem. Sure they are highly paid given the shortage (which motivates them even more to do quality work), but does that make projects more expensive in the end? I'm not convinced, and experience in other fields has often taught me otherwise. And given the current situation (you may wish it were different, it won't change reality), I think anyone serious about working as a software developer in the banking/financial domain should still learn COBOL. It's fine not to be interested in these domains whatsoever though.
There's no problem at all. The key problem is the celebration of this as a way of life. The world moved on and the only reason anyone is fanfaring this shit is to hide the legacy problems the business has.
Absolutely no one should be learning COBOL in 2020 entering the banking and financial sector.
Then of course comes the main point: maintaining and evolving legacy systems. Rewriting software from scratch has a long track record of spectacularly failed projects, in all kinds of domains.
That's a fair point. Only idiots rewrite systems from scratch and do a grand switch over. Migration to new tech should be a carefully controlled and phased "evolution". The platform I'm working on now is slowly eating away at legacy and moving over to a much more distributed model behind the existing interfaces. Eventually they will be replaced as well. But at no point is anyone pulling the plug and rewriting from scratch.
Lastly, as I said, COBOL seems to have evolved quite a bit, and I believe it even has object-oriented features these days.
It's really quite fugly though. Also most of our stuff isn't actually OO even though it's written in OO languages.
You can write bugs in COBOL too.
Of course. My point here was, using domain-specific languages, there's a whole range of bugs/security issues that you can avoid compared to using very general-purpose ones.
Yes we build domain specific languages to express complex problems as well. The matching engine above uses a DSL to define rule chains and a formal verification framework to validate them and the system behaviour afterwards (as it compiles them into parallel streaming implementation).
Shit's complicated!
FORTRAN was also another interesting example.
Of course you can write numerical analysis software in C, C++, Java, Pascal, Ada, whatever. (And I have - I'm not specifically advocating FORTRAN, I have never used it outside of uni.) But there's a good chance it'll take the average specialist more time, introduce more bugs, and will make them have to look for third-party libraries that may be costly or utterly buggy, or take months writing their own. So that's really about domain-specific languages and tools.
Most of our stuff is in C#. Including the numerical analysis stuff. Most of the modeling starts in Mathematica or Excel though or is which is how it goes these days.
-
I recently had a job upgrading a custom system with an obsolete language, it was quite obscure even at the time. There was literally only one guy in the company who knew how to build and use the run time debugger. The management thought it would be a quick upgrade, and had no budget for anything like improving the tools. I said right from the start it was going to take a lot longer than they thought, and sure enough the project went massively over schedule and over budget. The customer was so pissed off, they threatened to cancel but were too committed. They wrote an assessment report recommending that they never place an order with our company again.
The whole set up was really nothing like I had encountered before, but the really weird part is that the dysfunction was considered completely normal, and the only thing required was long working hours (unpaid overtime of course!). The management refusal to spend any time or money on improved tools, training, IT support etc guaranteed failure, but they were completely unable to see it. As far as they were concerned they had a "working product" which only needed minor changes. I had to quit for the sake of my health and sanity, I feel a little guilty about that because the rest of the guys would have to work even harder.
So it doesn't surprise me that technical debt can build up to a point where it is impossible to repay, and disaster is inevitable.
-
PROCEDURE DIVISION.
COBOL... take it out into the barn and shoot it.
Seriously, COBOL is the reason why IT departments have a wierdo employee who's been working in the same corner of the office since 1982. His cheese plant died in 1990, but he's still got the pot. And he's looking after some mysterous legacy database that's even older than the CTO. But only he understands the Db2 database syntax and, how to boot up that antique IBM workstation with the black and green VDU. And what that VDU is connected to, no-one knows. You can hear him tapping the SysReq key late at night, as he waits for the line printer to get spooled. The line printer died in a dumpster in 1998, along with his marriage.
-
PROCEDURE DIVISION.
COBOL... take it out into the barn and shoot it.
Seriously, COBOL is the reason why IT departments have a wierdo employee who's been working in the same corner of the office since 1982. His cheese plant died in 1990, but he's still got the pot. And he's looking after some mysterous legacy database that's even older than the CTO. But only he understands the Db2 database syntax and, how to boot up that antique IBM workstation with the black and green VDU. And what that VDU is connected to, no-one knows. You can hear him tapping the SysReq key late at night, as he waits for the line printer to get spooled. The line printer died in a dumpster in 1998, along with his marriage.
Man that is harsh, dude. Have some brotherly love for your fellow code-bro's.
I may slightly resemble some aspects of the depiction above. ;D
-
Just creep over there, drop a python book and run away :-DD
-
Yes, show some respect... maybe he is maintaining your company's payroll system that pays your salary every month...
-
Harsh, you ain't heard nothin' yet
Yes, show some respect... maybe he is maintaining your company's payroll system that pays your salary every month...
They would have upgraded payroll in 1991 to a bleeding edge RDBMs like Adabas/Natural. And then done nothing until the arival of a distruptive Javascript bootcamp graduate in 2014, whose system pays wages as random number strings via Paypal.
COBOL guy has seen them all come and all go.
-
Yes, show some respect... maybe he is maintaining your company's payroll system that pays your salary every month...
That's funny. My first proper IT job was replacing a System/360 and all the staff that ran the company's payroll. We joked that the entire dev cost was less than the electricity bill for the S/360 for a year :-DD
The system that replaced it was 16 bit VB and did the payroll run on a mid-range Pentium box faster than the S360 did and delivered it via EDI to the bank.
It has probably been replaced again since then I will add. I'm wondering how you'd get a mainframe running COBOL to integrate with OpenBanking or something :popcorn:
-
@bd139 I remember back in the day when EDI was the big new B2B voodoo (like blockchain is today). On our floor we had an EDI expert team. A bunch of intense ex-military types who thought lunch hour was for marathon training. My tech support team where just too busy fixing the leaking database to eat lunch.
Connecting COBOL to the cloud? I guess there's some amazon.elastic.crap.cobol.api for that? Back in the mainframe day, this was achieved with tape spools to magnetic cartridges using flaky JCL. Then mailing the cartridges to a data processing center somewhere in north London.
Thinks, is anyone still using MySQL outside of a Raspberry Pi?
-
Hahaha those guys still exist. Actually I just bagged a couple of Ciscos which were used as EDI diallers until very recently. :palm:
I know a guy with a large business running on MySQL. It’s still there. I wouldn’t go near anything other than Postgres and redis myself these days.
-
I wouldn't have any issues running production systems on MySQL, Postgres or even SQL Server.. It's not 2005 anymore, get over it.
-
SQL Server, SQLite and Postgres fine.
MySQL nope. It has done a thousand things to kill its reputation over the years. When there’s an option on the table I wouldn’t poke it with a stick. It doesn’t even deserve attention.